David and Dominic, Thanks to you both for your very helpful (though slightly disappointing) replies.
September 16, 2022 11:36 AM, "Thompson, David" <[email protected]> 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" <[email protected]> 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
