From: "Daniel Sockwell" <daniel@codesections.com>
To: "Dominic Martinez" <dom@dominicm.dev>,
"Thompson, David" <dthompson2@worcester.edu>
Cc: help-guix@gnu.org
Subject: Re: Understanding the Guix approach when language package managers are around
Date: Fri, 16 Sep 2022 22:16:52 +0000 [thread overview]
Message-ID: <c8d219a7480e0adb3a37601b48a4abc8@codesections.com> (raw)
In-Reply-To: <8735cr2qke.fsf@dominicm.dev>
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
next prev parent reply other threads:[~2022-09-16 22:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 13:15 Understanding the Guix approach when language package managers are around Daniel Sockwell
2022-09-16 15:36 ` Thompson, David
2022-09-16 16:57 ` Dominic Martinez
2022-09-16 22:16 ` Daniel Sockwell [this message]
2022-09-17 16:10 ` Dominic Martinez
2022-09-16 22:51 ` Philip McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8d219a7480e0adb3a37601b48a4abc8@codesections.com \
--to=daniel@codesections.com \
--cc=dom@dominicm.dev \
--cc=dthompson2@worcester.edu \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.