Re: Packaging a rust program with a lot of crates

[Wojtek Kosior]

Hi Paul!

> 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.

That's cool! Please keep in mind, tho that Guix is not an "easy" distro
for novice users. Be ready to spend even more time learning stuff :)

Having that said, the facilities Guix provides do allow for packages to
be created and maintained with relatively little time effort. I'm sure
learning will pay off!

> 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.

I'm also a novice when it comes to sending to guix-patches but I
believe the perfect approach in this case would be to:
- add each package with a separate git commit
- make sure the final package builds and works properly on your PC
- create a patch series comprising all the additions with `git
  format-patch` as described in the documentation
- describe in general what you did in series' cover letter that `git
  format-patch` generated for you
- send the cover letter to guix-patches mailing list with `git
  send-email` as described in the documentation; this will cause the
  debbugs instance to open a new bug
- wait for an email response from debbugs with your new bug's number
- send the rest of your patch series with one invokation of `git
  send-email --to=<BUG_NUMBER>@debbugs.gnu.org` as described in the
  documentation

This way the Guix committers will see all the package additions as
separate patches but grouped together in one debbugs issue. There's no
need to wait for one patch to be accepted before sending another in
this case.

> 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?

I'm not sure what you mean by this question.

Anyway, you just touched one unfortunate truth — when you're a
beginner, any serious task can easily take weeks.

My suggestion is that you start with something easier first. Perhaps an
application that only has 1 or 2 dependencies?

> 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?

There might be some misunderstanding here. Guix does allow
1. for multiple versions of the same package to coexist
2. and for multiple versions of the same package to share most of the
   packaging code via inheritance.
However, the possibility 1. is only exercised for some strategic
packages like gcc. For casual packages, when upstream releases a new
version, some kind Guix contributor sends a patch that changes the
definition in the .scm file to now describe the new version. The old
version need not be explicitly deleted — its place is taken by the new
version :)

Good luck and happy hacking ^^
Wojtek

pgpIIIo1VXEWB.pgp
Description: OpenPGP digital signature