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