On Mon, Feb 24, 2025 at 12:51:02PM -0300, Murilo wrote: > Hi Simon, thanks for bringing up the discussion again. > > On Fri Feb 21, 2025 at 11:23 AM -03, Simon Tournier wrote: > > How does it compare with antioxidant? And your (Nicolas) ideas? > > Antioxidant and Nicolas proposal is for a new build system (rust-build-system) > in Guix best aligned with we already do for other languages, which is using > libs shared and re-using previously pre-built stuff as inputs for a new > package > output.
In my tests a few years ago antioxidant was actually slightly faster compared to our standard method (3 minutes 45 seconds regular, 3:30 for antioxidant, I forget the package). It came with its own complexity however, and in the past 2.5 years no one has pushed it over the finish line. > Using rust-build-system comes with a major advantage: > - Lower build times, since we are only building every rust package once; > - Meaning Cuirass will build rust packages much much faster than when using > cargo; > - As an indirect consequence, other packages in guix are evaluated faster. > > In contrast, my proposal is to continue using the cargo-build-system, but > reorganize how we define and accept contributions for rust packages on > (gnu packages *) by transitively generating guix package definitions from > Cargo.lock. > > From my perspective it makes contribution easier because you need only to > generate the module contents, with, say, 'guix import' and send that isolated > module. > The module contents could be only origins, as Ludo' suggested, together with > the actual package definition for the rust app you're packaging. > > It also makes the maintainability of the rust ecosystem in guix easier: > > - "I want to update the 'melon' package." (the current guix way) > * I run 'guix refresh -u melon' to update the version and hash. > * 'guix build melon' > * Oh, guix has 'rust-orange@1.1.0' but it needs 'rust-orange@1.2.0'. > * I'll just update 'rust-orange'! > * But then I'll have to fix the 'strawberry' package that requires '= 1.1.0'. > Notice that because rust packages use #:cargo-inputs there's no easy and > documented way way to check the above, AFAIK, until cuirass complains about > it. > * I'll just make 'rust-orange-1' the new 1.2.0, and make a new > 'rust-orange-1.1' > for the 'strawberry' package. > It's easier to do this instead of patching the Cargo.toml because you don't > need to test if 'strawberry' works - a package that you never used before and > have no idea what is, you're just trying to update the 'melon' package. > When 'strawberry' updates, it will probably leave 'rust-orange-1.1' hanging. > * Make sure every affected package builds (even libraries which IMO shouldn't > be built). > * Write multiple commit messages for each package change across diferent > modules. To give an example of this, I recently updated rust-cargo and rust-cargo-c on the rust-team branch. I had 58 patches on top of just updating those two packages. The next package I updated was gitoxide, which took just one additional package. However! This isn't actually the case, I bumped gitoxide from 0.37.0 to 0.38.0, not to 0.41.0 so I could save myself another ~50 patches, but could be avoided by not packaging the latest version. Rust-cargo uses gix-0.67, and I found a version of gitoxide which uses the same version. I'm expecting to package gix-0.69 and 0.70 for different packages in the near future, both of which I expect to be about 50 patches. > - "I want to update the 'melon' package." (my proposed way) > * 'melon' package is in 'gnu/packages/rust/melon.scm'. > * I run 'guix refresh -u melon' to update the version and hash. > * I run 'guix import cargo melon', it fetches the 'Cargo.lock' from the > origin, > and generates the dependencies. > * I delete the entire 'gnu/packages/rust/melon.scm', except for the 'melon' > package, and paste the new generated cargo-inputs. > * Update 'melon' #:cargo-inputs to the newer generated ones. > These steps could be automated with a tool (perhaps attached to 'guix > refresh') to automatically do these trivial steps if we agree on sort of a > pattern/template for organizing rust apps. > * One single commit to the module update (because updates mostly won't affect > other modules). > > From my experience using this workflow on my personal channel I can package > most rust apps in less than 10-15 minutes (including build time), and updates > are really trivial to the point I can do even major version bumps in less than > 2 minutes (excluding build time, and including some manual editor steps which > could be automated). > > I'd like it too if we could get rid of #:cargo-inputs and use regular package > inputs, as Efraim noted. > I might be mistaken but I believe the new 'zig-build-system' does something > similar to how cargo works when building, and it used to have #:zig-inputs > in the WIP implementation which was rewritten later as regular input fields, > perhaps we could do some analogous work for 'cargo-build-system'. > > Best regards, > Murilo -- Efraim Flashner <efr...@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
