6 ms·

Since there aren't a lot of full time Haskell developers, I'm curious to know what do you use to setup your projects and handle dependencies: hsenv, cabal-dev,

Since there aren't a lot of full time Haskell developers, I'm curious to know what do you use to setup your projects and handle dependencies: hsenv, cabal-dev, cabal sandboxes, nix, stackage ... or do you include everything in your repository (any tool to automate that)?

progman 12y ago
I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!
- marcosdumay 12y ago
  You got very misinformed. Haskell is actually late to the sandbox party - up to recently you couldn't use them at all, and currently they are completely optional. But now that you can, it would be stupid to start a big project without them, like in any other language. Haskell package manager is called Cabal. Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment.
  - progman 12y ago
    You have misunderstood me. I know cabal - with and without sandbox. I said am amazed that sandboxes or nix tools are necessary in Haskell _at all_ while every other language which uses a package manager has one that works out of the box without any hassle and without any sandbox tricks. > Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment. Other Haskell developers don't agree. They prefer nix even over cabal sandboxes. Quote: "Nix helps me avoid Cabal hell" and "Nix is much better than cabal sandbox". https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-...
    - berdario 12y ago
      To be fair other languages need sandboxes as well: Virtualenv in Python and Bundler in Ruby fill the role But in a language like Haskell, a sandbox is definitely a subpar solution (glacial compilation times and huge artifacts sizes inside ~/.cabal: 1GB on my machine, compared to the few hundred MB of my ~/.m2). Unless we find a way to bootstrap a sandbox from a vetted/trusted base one that contains things like Yesod (but vetting packages is a job better handled by stackage and/or nix ). I use Nix, but I'm not comfortable yet in using it with Haskell... to try things quickly I'd need to whip up a nix-shell. But I'm more used to simply have easy access to a ghci repl at my fingertip. And if I install both things, I have to keep care at not trying to cabal install things onto the nix-installed ghc, nor to do the quick-and-dirty thing (go back to install things in ~/.cabal) Something like lein-try [1] plus Nix might cover my use cases. But Stackage seems simpler and closer to the workflow most haskell developers are accustomed with (and it could be useful also for platforms that don't have Nix available)... if only it'd have more adoption [1] https://github.com/rkneufeld/lein-try https://github.com/rkneufeld/lein-try
    - jmillikin 12y ago
      > every other language which uses a package manager has > one that works out of the box without any hassle and > without any sandbox tricks. I have programmed professionally with C, C++, Go, Haskell, Java, Javascript, Python, and Ruby. While this is not "every other language", I feel it's a sufficient cross-section to be useful for the purposes of this thread. Trying to do any sort of open-source development without a library sandbox, in any language, is madness. OS package managers are completely unable to deal with multi-version dependency graphs. NixOS is no different, unless you want to install the cartesian product of the possible combinations -- how much SSD space do you have? --- My experience with Haskell leads me to believe that "Cabal hell" is an artifact of certain library developers' API versioning philosophies. Namely, they release numerous libraries all depending on each other with tight version bounds, and change the API regularly. This behavior is fundamentally incompatible with dependency resolution in a compiled language. Say you have four libraries: foo-1.0 depends on bar==3.8 and qux==1.5 bar-3.8 depends on baz==0.2 and qux==1.5 baz-0.2 has no dependencies qux-1.5 has no dependencies Then tomorrow you want to release an API-incompatible version of qux and use those new features in foo: foo-1.1 depends on bar==1.1 and qux==1.6 bar-1.1 depends on baz==1.1 and qux==1.5 What do you do here? There's no good choice. Two versions of qux can't be linked into the same binary, and the tight API versioning prevents Cabal from being able to construct a coherent package set. Now imagine that instead of four libraries, it's O(50), and they're all changing regularly. Writing lots of tooling and writing manifestos against Cabal sort of helps, for a bit, but it's a lot of work and is deeply unsatisfying for the kind of person who likes to make progress on other goals. IMO the only practical solution is to loosen the dependency version bounds, and commit to maintaining API compatibility for several releases. I have never encountered Cabal hell when using packages with reasonable versioning philosophies.
Ixiaus 12y ago
Full-timer here. I use cabal sandboxes heavily and recommend you do so. Nix is great but you have to take some time to set it up and learn it - sandboxes are pretty standard and work as you would expect with ghc-mod (not that Nix doesn't I just had more time invested in getting it and the tooling setup to use it as a "dev environment" - cabal sandboxes are much simpler). Stackage is great too, btw.
- berdario 12y ago
  Thanks. Since we got the ball rolling (I planned to ask it on some mailing list, but I kept procrastinating to write a semi-formal mail). Do you know of any way to use multiple stackage repositories? (for now it's not a problem, but I envision a future when I'll have dozens of projects, and updating everyone of them to use the same library versions might not be feasible) I know that I can `cabal --config-file=/path/to/cabal.config` but I'm wondering if there's an easier way and/or any convention I'm especially worried of forgetting something (like reusing the same ~/.cabal for multiple stackage-cabal configs)
  - Ixiaus 12y ago
    I haven't actually tried to use multiple Stackage repos. I only think it's great because I helped a friend get started in Haskell and chose to see if Stackage would help with his cabal hell woes (it did and made the experience more pleasant). In general though, I think stuff like Stackage is a community smell and has the potential for creating a schism and confusion in the community. If it's community infrastructure I also feel like it should be controlled by haskell.org and not a for-profit company. I know I know, money and man-power are all issues but other OSS languages have successfully figured it out and I think Haskell can too. I personally use Nix for everyday development.
slashnull 12y ago
After a year or so of near constant dependency hell problems with Haskell, I stabilized all my setups on GHC7.8.3 and the associated Stackage inclusive, and it all... just... works... I can finally go and write some relevant code now.

progman 12y ago

I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!

marcosdumay 12y ago
You got very misinformed. Haskell is actually late to the sandbox party - up to recently you couldn't use them at all, and currently they are completely optional. But now that you can, it would be stupid to start a big project without them, like in any other language. Haskell package manager is called Cabal. Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment.
- progman 12y ago
  You have misunderstood me. I know cabal - with and without sandbox. I said am amazed that sandboxes or nix tools are necessary in Haskell _at all_ while every other language which uses a package manager has one that works out of the box without any hassle and without any sandbox tricks. > Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment. Other Haskell developers don't agree. They prefer nix even over cabal sandboxes. Quote: "Nix helps me avoid Cabal hell" and "Nix is much better than cabal sandbox". https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-...
  - berdario 12y ago
    To be fair other languages need sandboxes as well: Virtualenv in Python and Bundler in Ruby fill the role But in a language like Haskell, a sandbox is definitely a subpar solution (glacial compilation times and huge artifacts sizes inside ~/.cabal: 1GB on my machine, compared to the few hundred MB of my ~/.m2). Unless we find a way to bootstrap a sandbox from a vetted/trusted base one that contains things like Yesod (but vetting packages is a job better handled by stackage and/or nix ). I use Nix, but I'm not comfortable yet in using it with Haskell... to try things quickly I'd need to whip up a nix-shell. But I'm more used to simply have easy access to a ghci repl at my fingertip. And if I install both things, I have to keep care at not trying to cabal install things onto the nix-installed ghc, nor to do the quick-and-dirty thing (go back to install things in ~/.cabal) Something like lein-try [1] plus Nix might cover my use cases. But Stackage seems simpler and closer to the workflow most haskell developers are accustomed with (and it could be useful also for platforms that don't have Nix available)... if only it'd have more adoption [1] https://github.com/rkneufeld/lein-try https://github.com/rkneufeld/lein-try
  - jmillikin 12y ago
    > every other language which uses a package manager has > one that works out of the box without any hassle and > without any sandbox tricks. I have programmed professionally with C, C++, Go, Haskell, Java, Javascript, Python, and Ruby. While this is not "every other language", I feel it's a sufficient cross-section to be useful for the purposes of this thread. Trying to do any sort of open-source development without a library sandbox, in any language, is madness. OS package managers are completely unable to deal with multi-version dependency graphs. NixOS is no different, unless you want to install the cartesian product of the possible combinations -- how much SSD space do you have? --- My experience with Haskell leads me to believe that "Cabal hell" is an artifact of certain library developers' API versioning philosophies. Namely, they release numerous libraries all depending on each other with tight version bounds, and change the API regularly. This behavior is fundamentally incompatible with dependency resolution in a compiled language. Say you have four libraries: foo-1.0 depends on bar==3.8 and qux==1.5 bar-3.8 depends on baz==0.2 and qux==1.5 baz-0.2 has no dependencies qux-1.5 has no dependencies Then tomorrow you want to release an API-incompatible version of qux and use those new features in foo: foo-1.1 depends on bar==1.1 and qux==1.6 bar-1.1 depends on baz==1.1 and qux==1.5 What do you do here? There's no good choice. Two versions of qux can't be linked into the same binary, and the tight API versioning prevents Cabal from being able to construct a coherent package set. Now imagine that instead of four libraries, it's O(50), and they're all changing regularly. Writing lots of tooling and writing manifestos against Cabal sort of helps, for a bit, but it's a lot of work and is deeply unsatisfying for the kind of person who likes to make progress on other goals. IMO the only practical solution is to loosen the dependency version bounds, and commit to maintaining API compatibility for several releases. I have never encountered Cabal hell when using packages with reasonable versioning philosophies.

Ixiaus 12y ago

Full-timer here. I use cabal sandboxes heavily and recommend you do so. Nix is great but you have to take some time to set it up and learn it - sandboxes are pretty standard and work as you would expect with ghc-mod (not that Nix doesn't I just had more time invested in getting it and the tooling setup to use it as a "dev environment" - cabal sandboxes are much simpler). Stackage is great too, btw.

berdario 12y ago
Thanks. Since we got the ball rolling (I planned to ask it on some mailing list, but I kept procrastinating to write a semi-formal mail). Do you know of any way to use multiple stackage repositories? (for now it's not a problem, but I envision a future when I'll have dozens of projects, and updating everyone of them to use the same library versions might not be feasible) I know that I can `cabal --config-file=/path/to/cabal.config` but I'm wondering if there's an easier way and/or any convention I'm especially worried of forgetting something (like reusing the same ~/.cabal for multiple stackage-cabal configs)
- Ixiaus 12y ago
  I haven't actually tried to use multiple Stackage repos. I only think it's great because I helped a friend get started in Haskell and chose to see if Stackage would help with his cabal hell woes (it did and made the experience more pleasant). In general though, I think stuff like Stackage is a community smell and has the potential for creating a schism and confusion in the community. If it's community infrastructure I also feel like it should be controlled by haskell.org and not a for-profit company. I know I know, money and man-power are all issues but other OSS languages have successfully figured it out and I think Haskell can too. I personally use Nix for everyday development.

slashnull 12y ago

After a year or so of near constant dependency hell problems with Haskell, I stabilized all my setups on GHC7.8.3 and the associated Stackage inclusive, and it all... just... works... I can finally go and write some relevant code now.