Is it possible to design Stack (Haskell) just like NPM (NodeJS)?

Question

The Haskell Tool Stack is the most popular Haskell package manager for now, it's main goal is to make building haskell packages reproducible.

But the way stack approach it's goal is to find a huge no-conflict-set of package-revisions, and call it snapshot. In this way, the package maintainer is pushed to update his packages' dependencies so that it will not conflict with the recent snapshot.

I have to say, this design is too ideal to work in the real world.

For comparison, NPM (the package manager of NodeJS) approaches this goal via a more practical way: it allows redundancy. In diamond-rely-on case such as a -> b, c; b -> d(v1); c -> d(v2), NPM just install two different version of d separately for b and c. This way, users who using packages can depending on a package like a blackbox, no need to consider if there is conflicting-deep-dependencies between it's dependences.

I'm wondering is there some practical reason why Stack is not designed to allow redundant revisions of a package. Is it possible to implement such a package manager for Haskell? What is the hardest part of it's implementation?

Answer 1

Yes, it is possible. In fact, cabal used to work that way by default. It was abandoned in the move to nix-style builds, but as far as I know there's no technical problem standing in the way of doing it again.

That said, my experience with nix-style builds is that it is rare to find that forcing each package in the dependency tree to a specific version prevents you from being able to construct a build plan. I'm not sure whether this is so with stack, too -- I don't have much experience with it -- but at least for cabal at the moment there seems little benefit to doing that, and so the simple design with the simpler failure modes seems much more desirable.