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

[Dominic Martinez]

"Daniel Sockwell" <daniel@codesections.com> writes:

> 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

You've pretty much hit the nail on the head; Guix's dependency model is
much stricter than any language package manager, so unless you put the
(potentially significant) effort to package something in Guix, you'll
likely have to use the language tool directly. The strength of Guix is
that it 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.

I have a few fallbacks for when I can't work on a project in Guix:
1. Use Nix. Nix is more...liberal in their packaging, and so you still
lose out on the benefits of having packages defined from source, but you
can at least create a consistent working environment.
2. Use Docker. A docker container with a volume linked to your code is
almost always seamless.
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

signature.asc
Description: PGP signature