help-guix
[Top][All Lists]
Advanced

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

Re: Understanding the Guix approach when language package managers are a


From: Philip McGrath
Subject: Re: Understanding the Guix approach when language package managers are around
Date: Fri, 16 Sep 2022 18:51:37 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

Hi,

On 9/16/22 09:15, Daniel Sockwell wrote:
But looking into option 2 (packaging Chrysalis) doesn't seem promising
either.  My understanding is that packaging Chrysalis involves listing
its dependencies as `inputs`.  And that could be hard. Chrysalis has
~40 dependencies most of which aren't packaged for Guix.  And many of
those dependencies have their own transitive dependencies -- the full
graph seems to include 1,534 programs (for comparison, Guix currently
packages 51 `node-*` programs).  Given that I'm fairly new to Guix, I
very much doubt I should be trying to package a bunch of software.
Plus, even if I did, I doubt Guix would want to host an order of
magnitude more Node packages.  So, again, I get the sense that going
this route would be fighting against Guix instead of working with it.

So that's my question.  Are one of those approaches correct and I'm
just confused on the details?  Or is there some other approach to
installing this GPLv3 software that's the "real" Guix approach?  Or is
this sort of multi-dependency JavaScript app just a weak point for
Guix at the moment?

Thanks in advance for any insights you can provide.

Best regards,
Daniel


I think Guix would *love* to distribute an order of magnitude more Node packages, if only we could figure out how to do so well.

As others have said, using NPM directly is probably the pragmatic thing to do for now.

For option 2, though, there is a `wip-node-importer` branch in the Guix repository which I have found useful. There has been discussion on the lists about merging it, most recently, I think, in e.g. <https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00073.html> and <https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00076.html>. I continue to think we should merge it!

I had several thoughts on improving JavaScript things while working on <https://issues.guix.gnu.org/51838> (be warned it's a massive thread), but I haven't needed to do much JavaScript since, so I'm a little fuzzy on some of the details. I know one idea was that we look closely at PNPM, an alternative to NPM that has a content-addressed store and other features that seem relevant to Guix, and try to implement something similar in Guile, which might also let us unbundle NPM from Node.js. Some pointers along those lines:

- https://pnpm.io/symlinked-node-modules-structure
- https://pnpm.io/how-peers-are-resolved
- https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the-only-way
- https://medium.com/pnpm/pnpms-strictness-helps-to-avoid-silly-bugs-9a15fb306308
- https://pnpm.io/workspaces

-Philip



reply via email to

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