Hello, I hope this is the right place for this, apologies if it isn't. I'm working with a friend on a cargo importer that lowers the entry barrier and the maintainability costs for packaging rust apps in general, without sacrificing Guix dependency tracking and reproducibility of rust packages.
When you get used to the tool, you can pretty much package rust apps with all the dependency chain very easily (I just packaged [1] texlab for my channel earlier this morning in less than 5 minutes, and i can easily update apps to the latest version in less than a minute). Progress is being tracked in [2] if anyone wants to check it out or contribute to it. It is currently missing a lot of features, but we hope to improve the user experience of the tool in the near future. It is a very simple tool, it essentially parses the Cargo.lock file and extracts all the relevant information for constructing the rust package definitions of all the cargo-inputs and the package itself, and outputs to stdio a guile module containing all the needed cargo-input chain as guix packages, with all the cargo-inputs self-contained and versions all sorted out for a working final package build. This way a packager only needs to focus on the actual package they are trying to build, instead of worrying about its cargo-inputs. Due to how cargo-inputs are organized in gnu/packages/crates-*.scm, and some current packaging guidelines for crates on Guix, we cannot simply contribute these self-contained packages generated directly from the Cargo.lock, thus requiring to use the guix crate importer and spending a lot of time fixing dependencies and worrying about other packages breaking in the process. I would like to propose some discussion around a better way of organizing the rust packages and its cargo-inputs in (gnu packages) for building rust apps that only need sources as cargo-inputs: 1) Create a new directory at gnu/packages/rust/ in which a contributor can commit self-contained rust apps scm modules. 2.1) Add a new module at gnu/packages/rust/my-rust-app-1.scm 2.2) Add a new module at gnu/packages/rust/my-rust-app-2.scm 3) All package definitions inside gnu/packages/rust/*.scm which are source-only (#:skip-build? #t) should not be exported. 4.1) gnu/packages/crates-*.scm will not cease to exist, existing rust apps packages that have a Cargo.lock could gradually be migrated to the new organization 4.2) libs which need to be built can still live in gnu/packages/crates-*.scm 5) A (define-public my-rust-app-1 (@@ (gnu packages rust my-rust-app-1) my-rust-app-1)) or equivalent could be done in a (gnu packages category) module to export the rust app in the desired category. 6) Unlike nix (which also parses the Cargo.lock in the build system), we don't lose the ability to make snippets for sources this way. 7) For updating/maintaining a rust package defined this way, one would be able to simply re-run the guix tool, and replace the gnu/packages/rust/my-rust-app.scm file, only copying over the final relevant package definition for the rust app with its tweaks for building, and passing over the new cargo-inputs generated by the guix tool. I believe that by only changing the way things are organized and having a guix tool that generates self-contained package definitions from Cargo.lock, it would be possible to greatly improve the time required for contributing new rust apps packages and maintaining them on Guix. Things don't need to be the way I described here, these are just my initial thoughts after several failed attempts and wasted time trying to contribute rust apps to Guix, I'd like to discuss workarounds and if the benefits are greater than the disavantages for an approach like this. The tool we made works really well for packaging for our personal channels, I am very satisfied with how easy it is, and I think Guix could benefit a lot by adopting a similar approach. What am I missing here? Are there any disavantages to this approach? Anything that would break from it if adopted on Guix? Any questions or suggestions? Murilo [1] https://codeberg.org/look/saayix/commit/c7643943545d62baba80cccee1650ebf94362858 [2] https://git.sr.ht/~look/cargo2guix
