4 ms·

Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cuttin

Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cutting edge stuff like Nixpkgs) and Stack is by far my favorite. EDIT: To elaborate on why I like Stack: + Fully declarative. I don't run commands to edit my Stack environment, instead I modify the relevant stack.yml file. This means that the current environment can always be easily examined, committed to Git, etc. + Easy NixOS integration which means I can also describe the non-haskell dependencies for a project, and enforce that _absolutely_ nothing else on my system gets used. This is amazing. + I like that it uses Stackage by default, and that I can pin projects to LTS Stackage releases. This means that many users of my projects will probably already have most dependencies installed -- especially cool for small things like tutorials where users won't have the patience for long build times. + It reuses the already existing `.cabal` file format so it's easy to make libraries compatible with cabal-install, the other package manager in the Haskell ecosystem.

saysjonathan 10y ago
You're clearly very into Stack. If you're interested though, cabal-install 1.24 introduced nix-style local builds.
- seagreen 10y ago
  Hey! So I'm deeply appreciative towards cabal-install for historical reasons. The situation before cabal-install was . . . not the best (https://www.gwern.net/Resilient%20Haskell%20Software https://www.gwern.net/Resilient%20Haskell%20Software) so I think we can credit cabal-install with a lot of the success the ecosystem has had over the last decade. That said, nix-style builds don't actually address my issues with cabal-install. My (very personal) preference is to always have the current dependencies being used reflected exactly in a local file. I picked up this attitude from NixOS, but it's an extremely useful way of doing things -- the knowledge that as long as I don't lose that file I can always rebuild my current environment exactly is just too awesome. I think that if you need to track version bounds as well (say you're developing a library) they should be kept in a separate file, and you should always have a master file that describes what you're currently using locally. Happily this is exactly what Stack does with my-project.cabal and stack.yml. That said, I appreciate that others like cabal-install, so I do what I can to make my code easy to use with both package managers (the main thing is keeping aggressive upper bounds on the few libraries I maintain, which especially helps cabal-install users since they do dependency solving more).
Ericson2314 10y ago
Stack fixes some things, but as am additional layer of abstraction leaves lots of problems in place.

saysjonathan 10y ago

You're clearly very into Stack. If you're interested though, cabal-install 1.24 introduced nix-style local builds.

seagreen 10y ago
Hey! So I'm deeply appreciative towards cabal-install for historical reasons. The situation before cabal-install was . . . not the best (https://www.gwern.net/Resilient%20Haskell%20Software https://www.gwern.net/Resilient%20Haskell%20Software) so I think we can credit cabal-install with a lot of the success the ecosystem has had over the last decade. That said, nix-style builds don't actually address my issues with cabal-install. My (very personal) preference is to always have the current dependencies being used reflected exactly in a local file. I picked up this attitude from NixOS, but it's an extremely useful way of doing things -- the knowledge that as long as I don't lose that file I can always rebuild my current environment exactly is just too awesome. I think that if you need to track version bounds as well (say you're developing a library) they should be kept in a separate file, and you should always have a master file that describes what you're currently using locally. Happily this is exactly what Stack does with my-project.cabal and stack.yml. That said, I appreciate that others like cabal-install, so I do what I can to make my code easy to use with both package managers (the main thing is keeping aggressive upper bounds on the few libraries I maintain, which especially helps cabal-install users since they do dependency solving more).

Ericson2314 10y ago

Stack fixes some things, but as am additional layer of abstraction leaves lots of problems in place.