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. 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. - "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
