unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Paul Collignan <paul.collignan@aquilenet.fr>
To: help-guix@gnu.org
Subject: Packaging a rust program with a lot of crates
Date: Wed, 12 Jul 2023 16:24:42 +0200	[thread overview]
Message-ID: <ZK63qqNt7KMLFHH2@Amsterdam> (raw)

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


             reply	other threads:[~2023-07-15 13:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12 14:24 Paul Collignan [this message]
2023-07-15 14:06 ` Packaging a rust program with a lot of crates Wojtek Kosior via
2023-07-15 15:10   ` Paul Collignan
2023-07-15 16:16     ` Wojtek Kosior via
2023-07-23 12:46     ` Hartmut Goebel
2023-07-17 16:05   ` wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZK63qqNt7KMLFHH2@Amsterdam \
    --to=paul.collignan@aquilenet.fr \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).