Hello, Efraim Flashner <efr...@flashner.co.il> skribis:
> I don't want to go and parse Cargo.lock, automagically generate packages > based on that, and then download those as cargo-inputs for packages. Not > only does that potentially pull in old versions of libraries which may > have necessary updates or patches, it doesn't check them for license > data or vendored C libraries. Yes, that makes sense to me. A corollary is probably that Guix itself should only focus on a subset of available Crates, with a line drawn somewhere. This needs to be spelled out so contributors and users know what to expect. > I am jealous of the cran updater and all the work Rekado has put into > making it work well, and I know I need to actually fix a bunch of stuff > with the crates. An updater and also the etc/committer.scm file. There > are too many crates to actually package them all, so that wouldn't be > something workable to automatically package all of them. > > I have a script that goes through the crates and lists how many > dependencies there are per file, and I have used it in the past to > remove unused crates. I have also come back and added them back in when > something else needed them. The problem is that currently tools that work for the rest of Guix don’t work for Crate packages. There’s the proposal at <https://issues.guix.gnu.org/53127>, there’s also antioxydant, and there’s your script and other tools people might have. I think this needs to be consolidated so that things remain under control. Ludo’.
