3 ms·

I felt that way up until last week! I somehow felt I was special, that cabal-hellfires had burnt a ring around me. Then next thing I knew I had a 4 page cabal c

by tel 14y ago

I felt that way up until last week! I somehow felt I was special, that cabal-hellfires had burnt a ring around me. Then next thing I knew I had a 4 page cabal conflict problem and had to just toast .ghc and .cabal and start over. It's a real problem.

carterschonwald 14y ago
use Cabal-Dev! Also the next major release of cabal should have a lot of the cabal-dev machinery baked in. Theres also active brain storming by GHC dev folks on how to make things better on the compiler side too.
papsosouid 14y ago
Your response makes it sound like you just had a simple problem like you get with any language, and followed bad advice on solving it based on the assumption that "cabal is just bad and you have to do this". The big give away is that you didn't need to delete your .cabal directory, advice to do so is coming from someone who doesn't know the basics of how cabal works. It is just storing downloaded sources, all deleting it accomplishes is making you re-download stuff for no reason. The installed packages are in your .ghc directory. Cabal is no more broken than cpan.
- tel 14y ago
  You're right that I'm not very fluent on how Cabal works. It worked well enough that I didn't really need to until recently. I'm not claiming either that CPAN is better than Cabal. Could versioning be done better? Probably. I don't even claim to know enough to have a competent suggestion as to how, though. Doesn't mean things don't break, though.
  - papsosouid 14y ago
    >Doesn't mean things don't break, though. Right. The issue is that cabal has unfairly developed a reputation as being broken. People always say stuff like "every other language has this sorted out, why is haskell so bad at it?". When the reality is that the problems you get with cabal are the same ones you get with cpan or pip or anything else.
    - tel 14y ago
      They're slightly exacerbated in that Cabal/GHC/Haskell type checks and thus has a higher likelihood of discovering mismatches.
gtani 14y ago
you could look into hsenv and cabal-dev. https://github.com/cakesolutions/the-pragmatic-haskeller https://github.com/cakesolutions/the-pragmatic-haskeller http://bob.ippoli.to/archives/2013/01/11/getting-started-with-haskell/ http://bob.ippoli.to/archives/2013/01/11/getting-started-wit... Also, problems in the haskell ecosystem don't stay problems for long, this one is the longer end of the tail http://alpmestan.com/posts/2012-11-02-cabal-hackage-what-you-can-do-about-it.html http://alpmestan.com/posts/2012-11-02-cabal-hackage-what-you...
- tel 14y ago
  I do use .hsenv a lot, but for simple playing around with libraries (where I'm also most likely to hit major version overlaps) I liked to keep installing packages into the user level database.

by tel 14y ago

carterschonwald 14y ago

use Cabal-Dev! Also the next major release of cabal should have a lot of the cabal-dev machinery baked in. Theres also active brain storming by GHC dev folks on how to make things better on the compiler side too.

papsosouid 14y ago

Your response makes it sound like you just had a simple problem like you get with any language, and followed bad advice on solving it based on the assumption that "cabal is just bad and you have to do this". The big give away is that you didn't need to delete your .cabal directory, advice to do so is coming from someone who doesn't know the basics of how cabal works. It is just storing downloaded sources, all deleting it accomplishes is making you re-download stuff for no reason. The installed packages are in your .ghc directory. Cabal is no more broken than cpan.

tel 14y ago
You're right that I'm not very fluent on how Cabal works. It worked well enough that I didn't really need to until recently. I'm not claiming either that CPAN is better than Cabal. Could versioning be done better? Probably. I don't even claim to know enough to have a competent suggestion as to how, though. Doesn't mean things don't break, though.
- papsosouid 14y ago
  >Doesn't mean things don't break, though. Right. The issue is that cabal has unfairly developed a reputation as being broken. People always say stuff like "every other language has this sorted out, why is haskell so bad at it?". When the reality is that the problems you get with cabal are the same ones you get with cpan or pip or anything else.
  - tel 14y ago
    They're slightly exacerbated in that Cabal/GHC/Haskell type checks and thus has a higher likelihood of discovering mismatches.

gtani 14y ago

you could look into hsenv and cabal-dev. https://github.com/cakesolutions/the-pragmatic-haskeller https://github.com/cakesolutions/the-pragmatic-haskeller http://bob.ippoli.to/archives/2013/01/11/getting-started-with-haskell/ http://bob.ippoli.to/archives/2013/01/11/getting-started-wit... Also, problems in the haskell ecosystem don't stay problems for long, this one is the longer end of the tail http://alpmestan.com/posts/2012-11-02-cabal-hackage-what-you-can-do-about-it.html http://alpmestan.com/posts/2012-11-02-cabal-hackage-what-you...

tel 14y ago
I do use .hsenv a lot, but for simple playing around with libraries (where I'm also most likely to hit major version overlaps) I liked to keep installing packages into the user level database.