Back

@anemofilia thanks for the tool.

@civodul The main difference is that while 'guix import crate' fetches things from crates.io (which is an online registry for rust crates), cargo2guix doesn't necessarily needs internet access to generate the package definitions.
It accomplishes that by reading the lock file generated by cargo (rusts package manager) and subsequently generating the guix package definitions based on what the 'Cargo.lock' provides. So basically creating transitive package definitions from 'Cargo.lock' as a source.

@civodul Because of the nature of the cargo package manager, cargo dependencies are statically linked, meaning you can have the whole 'gnu/packages/crates-*.scm' with '#:skip-build? #t', save a TON of cuirass time, because for every rust program you compile, the whole rust dependency chain is compiled once again anyways, so you don't actually need to build the libraries like guix does atm.

@civodul This is also a *huge huge* waste of time when contributing rust apps to guix because sometimes these libraries need some really complicated tweaking (or hundreds of additional crates) to satisfy their own 'build' phases, which aren't needed when you only want to use the library as a dependency for some rust program.

@civodul The main benefit I personally take advantage of from cargo2guix is it being able to generate a fully self-contained list of rust package dependencies. This means the package will necessarily build no matter what, as long as the main package definition is correct.
See for example the rust module in my personal channel [1].

[1] https://codeberg.org/look/saayix/src/branch/entropy/saayix/packages/rust

@civodul Each one of these .scm files can be self-contained, meaning you don't need to import any (gnu packages crates-*) modules for the package to build, which makes updating and bumping rust packages extremely easy (I've been updating these rust apps for almost a year now in less than 3 minutes, even when major version bumps happen and the whole dependency chain changes significantly).

@civodul Right now cargo2guix uses a hybrid approach, it prioritizes getting crates from already existent (gnu packages crates-*) modules if their semantic versions are compatible with what the Cargo.lock specifies. If the semantic version is not compatible, it bootstraps a new dependency package definition with '#:skip-build? #t' using the version specified by the lock file.

@civodul We made cargo2guix because I once wanted to try out helix (my current text editor) which is not on crates.io, so 'guix import crate' doesn't work for it.
A thing I wish I knew before I started: @anemofilia wrote a language parser from scratch for parsing 'Cargo.lock', but that was not needed because cargo locks are TOML.
So the goal for when contributing a 'guix import cargo' is to make it use a proper TOML parser instead, should be really easy infact.

@civodul Another thing is we lose on #:cargo-development-inputs, as those are not tracked in the usual 'Cargo.lock'.

@civodul I sent an email a while ago on guix-devel [2] explaining all of the above and proposing some discussion around the current bad sides of the current way we handle rust packages on guix, and how we could make it better. I guess people aren't really interested in discussing it.
I now know a lot more about the 'cargo-build-system' than I did when I wrote that, so some of the suggestions I sent there could be a bit more polished.

[2] https://lists.gnu.org/archive/html/guix-devel/2024-05/msg00166.html

@look Yeah, I think few people want to take care of it, but many like myself think that something should be done about it. :-)

We definitely need to rethink how we approach Rust packages, with two things in mind: sustainability/maintainability and good use of computing resources.

With approach 4, I have spent less than 10 minutes to make a basic package for atuin from scratch. However the cost is I have to put 505 dependencies into its inputs field...

@zimoun@social.sciences.re @look@fosstodon.org @civodul@toot.aquilenet.fr @alxsim@ecoevo.social @anemofilia@mathstodon.xyz

@hako Where each of the 505 dependencies is represented as an origin?

@look @anemofilia @zimoun @alxsim

@civodul@toot.aquilenet.fr Yes, all the dependencies are defined as origins in a single module.

The current cargo-build-system actually already supports this approach well without modification by unpacking crates from inputs (#:cargo-inputs -> expand-crate-sources -> #:inputs passed to build system).

I think package-specific input lists can be defined in the module to 1. avoid extreme long lines in package definition 2. limit all generated definitions in one module.

@look@fosstodon.org @anemofilia@mathstodon.xyz @zimoun@social.sciences.re @alxsim@ecoevo.social

My work continues here, I'll integrate cargo2guix next and I think a working demo will be available within this week.

https://git.boiledscript.com/hako/guix/commits/branch/origin-crates

@civodul@toot.aquilenet.fr @look@fosstodon.org @anemofilia@mathstodon.xyz @zimoun@social.sciences.re @alxsim@ecoevo.social

@hako Nice! Make sure to chime in in the discussions on guix-devel.

@look @anemofilia @zimoun @alxsim

@zimoun Do you think it would be possible also the equivalent of guix-cran for crates? This would be a way to have all major versions of rust crates in a relatively automatic manner no?

@alxsim Well, on the paper, yes! For real it’s more complicated, IMHO.

For two reasons: 1. R folks value a lot robustness and stability while Rust (or Julia or etc.) clearly not! Instead they value efficiency and fast deployements.

2. R package management is quite “simple“ while Rust (or Julia or etc.) not! Cargo tries to be “smart” because they want to be “easy”.

@alxsim In other words, 2. means that either a) many of the “smart” logic implemented inside Cargo (or Pkg.jl or etc.) should be somehow re-implemented in the Guix importer or b) the Guix importer should somehow include direct calls of Cargo (or Pkg.jl or etc.).

That’s said, yeah Guix has to improve the situation considering how Rust is becoming more and more popular in various fields… Arf! The plate’s never empty.