Re: Packaging a rust program with a lot of crates

[wolf <wolf@wolfsden.cz>]

[-- Attachment #1: Type: text/plain, Size: 4108 bytes --]

On 2023-07-15 16:06:56 +0200, Wojtek Kosior via wrote:
> 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 :)

Is there a way to mark a package as a dependency?  I can very well imagine that
new version of some golang program would require less dependencies, but it is
very easy to forget to remove the package definition.  Is there a reasonable way
to clean this up?

> 
> Good luck and happy hacking ^^
> Wojtek

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]