Можно ли спроектировать стек (Haskell) так же, как NPM (NodeJS)?

Question

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * [$ 1003].огромный бесконфликтный набор пакетов-ревизий, и назовите его snapshot.Таким образом, сопровождающий пакета вынужден обновлять зависимости своих пакетов, чтобы он не вступал в конфликт с недавними snapshot.

Я должен сказать, что этот дизайн слишком идеален для работы в реальном мире..

Для сравнения, NPM (менеджер пакетов NodeJS) подходит к этой цели более практичным способом: он допускает избыточность.В случае с бриллиантами, например a -> b, c; b -> d(v1); c -> d(v2), NPM просто устанавливает две разные версии d отдельно для b и c.Таким образом, пользователи, использующие пакеты, могут зависеть от пакета, такого как черный ящик, не нужно учитывать, есть ли конфликтующие-глубокие зависимости между его зависимостями.

Мне интересно, есть ли практическая причина, почему стекне предназначен для разрешения избыточных версий пакета.Возможно ли реализовать такой менеджер пакетов для Haskell?Что самое сложное в его реализации?

Answer 1

Да, это возможно. Фактически, cabal по умолчанию работал таким образом. Он был заброшен при переходе к сборкам в стиле nix, но, насколько я знаю, нет никаких технических проблем, мешающих сделать это снова.

Тем не менее, мой опыт работы со сборками в стиле nix заключается в том, что редко можно обнаружить, что принудительное приведение каждого пакета в дереве зависимостей к определенной версии не позволяет вам составить план сборки. Я не уверен, так ли это и с stack - у меня нет большого опыта с этим - но по крайней мере для cabal на данный момент кажется, что это мало что дает, и так просто дизайн с более простыми режимами отказа кажется гораздо более желательным.