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

[Thompson, David]

Hi Daniel,

On Fri, Sep 16, 2022 at 10:48 AM Daniel Sockwell
<daniel@codesections.com> wrote:
>
> Hi all,
>
> (I also asked this question in r/guix; sorry if you're seeing it
> twice.)
>
> I'm trying to understand how Guix "wants" me to install software
> that's in language package managers, such as npm, Leiningen, etc.
> My current approach to installing some non-packages software
> gives me the feeling that I'm fighting against Guix -- usually a
> clear sign that I'm missing something.
>
> Here's a specific example (though note that I'm asking about overall
> approaches; I'm not currently seeking help debugging this specific
> install).  I use a keyboard with open-source firmware and would like
> to install the configuration utility, Chrysalis
> (https://github.com/keyboardio/Chrysalis) for that firmware.
>
> My first step, of course, was to check if Guix packages Chrysalis
> (it's licensed under GPLv3, so we could); but we don't package it.
> From the project `README`, I see that Chrysalis is distributed as an
> AppImage, so on any other distro I'd use that.  However, I know that
> AppImages don't cooperate well with Guix, so that's out.  The `README`
> also shows that Chrysalis is a JavaScript program (actually an
> Electron app), so the normal/non-Guix installation would be to run
> `npm install` and go from there.
>
> I can think of two ways to proceed:
>
>   1. Install Node/npm and attempt to install Chrysalis just like I
>   would on any other distro

This is the way I would recommend, if you can get it to work.

>   2. Attempt to package Chrysalis via Guix (probably using the
>   `node-build-system`) and then install it normally

As you explain below, here be dragons. :(

> But both of these approaches give me the feeling that I'm Doing It
> Wrong™.  With the first, I immediately hit errors about libraries not
> being where Node expected.  I might be able to work around those (a
> guide on the mailing list seems promising
> https://lists.gnu.org/archive/html/help-guix/2018-06/msg00052.html).
> But, even if I did, I'd be left with a package that is entirely
> outside Guix's functional model -- which seems like a hint that this
> isn't the Guix approach.

Yes, ideally, everything could be managed with Guix.  However, with
node, this is the best that you can do right now.

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

Unfortunately, you're right.  Many have tried to untangle the mess,
but no one has succeeded.  Here's a blog post from 2015 that
illustrates some of the problems:

https://dustycloud.org/blog/javascript-packaging-dystopia/

Unfortunately, the problems are still the same in 2022.  Huge
dependency trees with likely multiple versions of *the same library*
in it, circular dependencies when "dev dependencies" (aka the stuff
you need to build from source) are taken into account, missing
licenses, binary blobs with no source, proprietary code, etc.  It's a
real mess.

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

Guix's highly reproducible, source-based approach is very much at odds
with the npm model of distribution which is effectively the polar
opposite.  If you can sort out your issues with making the npm tool
work on a Guix system, I would just go that route for lack of a
feasible alternative.

Sorry for the bad news!  Good luck!

- Dave