Idea for packaging rust apps

["Murilo" <murilo@disroot.org>]

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