Understanding the Guix approach when language package managers are around

[Daniel Sockwell]

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

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

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.

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

--
Daniel Sockwell / codesections
website:  www.codesections.com