[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Packaging a rust program with a lot of crates

From: Paul Collignan
Subject: Packaging a rust program with a lot of crates
Date: Wed, 12 Jul 2023 16:24:42 +0200


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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]