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

> 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?)

Guix is great at solving the diamond dependency problem, but exactly
representing that dependency structure implies an exponential number of
package definitions. Usually packagers will try to find the minimal
number of package versions that satisfy the requirements of their
dependents, but when having multiple major versions of packages in your
dependency tree is practically a given, it's a lot of duplication.

Also consider that by default, module resolution is tied to the folder
structure of 'node_modules', so as Philip said we'd have to re-implement
PNPM's logic:
https://pnpm.io/motivation
https://npm.github.io/how-npm-works-docs/npm3/non-determinism.html
https://npm.github.io/how-npm-works-docs/npm3/duplication.html

>> 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?

If I'm just trying to have a more standard Linux environment I usually
don't feel the need to use docker compose. You can just have a script
that builds your environment, and another that launches the container in
a directory:

$ docker build -t <tag> - < <Dockerfile> # Build the image
$ docker run -it --rm -v ${1}:/src <tag> # Run the image, bringing in a directory