|
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
[Prev in Thread] | Current Thread | [Next in Thread] |