[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Understanding the Guix approach when language package managers are a
Re: Understanding the Guix approach when language package managers are around
Fri, 16 Sep 2022 22:16:52 +0000
David and Dominic,
Thanks to you both for your very helpful (though slightly
September 16, 2022 11:36 AM, "Thompson, David" <firstname.lastname@example.org> 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:
> 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).
(Or am I confused about what you meant or how Guix works?)
September 16, 2022 12:57 PM, "Dominic Martinez" <email@example.com> wrote:
> [Guix] provides a single, consistent interface for packages, but it's
> around "download and run this mysterious blob".
> For other languages guix import can help, but right now Guix does not
> 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
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
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!