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

[Daniel Sockwell]

David and Dominic,

Thanks to you both for your very helpful (though slightly
disappointing) replies.

September 16, 2022 11:36 AM, "Thompson, David" <dthompson2@worcester.edu> wrote:
> 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.

That's too bad.  I'm glad to no longer be working primarily
in JS but there's a lot of great free software written in 
the language and missing out on easy access to it is a shame.

> [A JS project will often have huge] dependency trees with 
> likely multiple versions of *the same library* in it

But isn't that something that Guix is really *good* at handling?
My understanding is that one of Guix's selling points is that it
allows package A to depend on both B and C even if B and C depend
on different versions of D (aka, the diamond-dependency problem).
So maybe Guix would be a better JavaScript package manager than
NPM is!

(Or am I confused about what you meant or how Guix works?)


September 16, 2022 12:57 PM, "Dominic Martinez" <dom@dominicm.dev> wrote:
> [Guix] provides a single, consistent interface for packages, but it's
> significantly at odds with the Javascript/Python ecosystems that evolved
> around "download and run this mysterious blob".
> 
> For other languages guix import can help, but right now Guix does not
> have a consistent way to package Javascript, which is why so few
> packages are currently available.

Thanks, that makes sense.

> I have a few fallbacks for when I can't work on a project in Guix:
> ...
> 2. Use Docker. A docker container with a volume linked to your code is
> almost always seamless.

Ah, that's a good option.  I experimented with some of Guix's --container
options but didn't consider using docker directly.  I take it that's what
you do?  Do you use docker compose and/or do anything to make your docker
containers more functional/fit better with Guix? 

> 3. The upcoming --emulate-fhs option. This isn't merged yet, but
> you can build Guix with the following patches so that downloaded
> binaries will see system libraries: https://issues.guix.gnu.org/56677

Ooh, that looks *very* cool and might be exactly what I need!  It might
not solve the problem for JavaScript packages, where NPM really is 
diametrically opposed to the Guix approach.  But I spend most of my
time writing Raku these days, and Raku's approach to package management
is quite a lot like Guix's -- it even installs programs to immutable
directories named based on a hash, see 
https://docs.raku.org/language/compilation
So exposing just a few system libraries to Raku programs could be
perfect for getting the two package managers to work well together!

Thanks again to you both!

Best,
Daniel