Packaging a rust program with a lot of crates

[Paul Collignan <paul.collignan@aquilenet.fr>]

Hi,

First of all I would like to apologize if the answers to my questions are obvious. This is a first for me in many areas. First mailing list, first time I want to contribute to a free project, first time I have to write something in a programming language, first time I use git, etc. I'm not a computer scientist at all. At best you could call me a GNU/Linux end user for some time, but only to consume, never to produce. I would like to contribute a little, and for that I want to start with guix.

So I discovered guix last week, and spent the last few days reading the documentation and playing with it. I would like to package a program that I use on my computer but which is not in the repositories. It turns out to be a program written in Rust, with lots of dependencies. If I were to copy/paste all of what guix import -r returns the patch would be over 3000 lines long.

I would like to know what are the best practices to adopt in this case. There are simple additions, updates, and additions with inheritance. I guess I shouldn't send a patch with all of this mixed up.

Should I group crates by "logical patches", say slicing by origin url (like a first patch with all related to microsoft/windows-rs), wait for that patch to be accepted, then send the next one? Or maybe I should send one patch per package update first, then one patch per package with inheritance, then one patch with all the simple additions?
Or a mixture of these two proposals?

Also, in this kind of case, I think that adding the program will take  weeks when you're a beginner like me. Did I miss something? For example, is it possible to automate package inheritance during an update to a major version of a crate, or does it have to be done by hand?

Last question, for my culture, is there a plan to "clean up" old packages and dependencies that are no longer used, or will the scm files grow indefinitely?

Thanks for your help,
Paul