On Fri, 07 Mar 2025 01:24:28 +0800, Efraim Flashner wrote: > > > 4. Check module diff, content of sources marked as TODO and output of > > 'check-for-pregenerated-files phase. > > After the backdoor in xz being hidden in a test tarball I'm not going to > suggest we drop scanning the test directories, but if we were to go > through the cargo sources and delete tests and examples it would make > them a bit smaller and also speed up that phase.
Sure, this can be done. These sources won't show up in ‘guix build --source’ result anyway. > I decided to go for uv, which is a python package manager. The TODO > comments were good, and I believe I unbundled everything from them. I > mostly copied the snippets from the existing packages, but as we package > more they'll transition over to rust-crates.scm and we'll be able to > copy changes from there. > > I had 4 dependencies which needed git-fetch, and I packaged them in > rust-crates.scm also. I tried changing the names to > rust-xx-for-uv.tar.gz, but that didn't trick cargo into unpacking them. > In the end I had to add them as inputs and copy them over manually. One > of them, version-ranges, was inside a directory of another one, which > was annoying to figure out, and I think would've needed manual > intervention even if git sources were unpacked automagically. pubgrub is a workspace, so it need to be packaged standalone. The other 3 look like valid use cases to add back the support :) > I copied the arguments from fish for the modules and the > 'prepare-cargo-build-system phase, which was really nice. Then I had > another couple of phases I had to add myself; the 'install phase from > pyproject didn't handle binaries, 'install-extras had to generate the > shell completions and I spent some time figuring out if there were man > pages. > > Overall I think I spent about 3 hours packaging uv. uv itself has a 10 > minute build time on my machine, the check for binary files took about > 60 seconds and each attempt to run the tests took an additional 10 > minutes. I'm not sure how many crates already exist in crates-* modules > or which ones would need updating if we did it traditionally, but I > spent most of the time fighting the 'install and 'check phases. > Considering we don't care about the input crates except for the licenses > and security problems, using cargo-audit and cargo-license really did a > great job of taking care of all of that. > > I've attached the 2 patches I created. I like how I only needed to > fight with the final package to get it to work. And I really like the > 'prepare-cargo-build-system combo phase that can be dropped into other > packages as needed. I think we should see about switching some of the > other packages from the cargo-build-system back to their preferred build > system. As replied in Go related thread, I'm thinking of maintaining rust-crates.scm separately, in a dedicated repo or branch, doing cleanup only in scheduled time and maybe adding versions to *-cargo-inputs as well. Then this file will be compatible with most changes on the main branch. Whenever there's conflict in rust-crates.scm, just copy the file over.
