3 ms·

Cabal hell hasn't existed for quite a while. See https://cabal.readthedocs.io/en/3.4/nix-local-build-overview.html https://cabal.readthedocs.io/en/3.4/nix-loca

by tome 6y ago

Cabal hell hasn't existed for quite a while. See https://cabal.readthedocs.io/en/3.4/nix-local-build-overview.html https://cabal.readthedocs.io/en/3.4/nix-local-build-overview...

srtjstjsj 6y ago
Nix doesn't solve the problem of incompatible versions in one binary. Nix only solves the problem of finding compatible versions if they exist. Cabal hell is more than one problem.
- shirogane86x 6y ago
  nix-style local builds (although the name is kinda bad) don't really have anything to do with nix, they're only the (admittedly bad) name for the new v2-* style commands (that now, at least as of cabal-3.0.0.0 and higher, are the default)
  - tome 6y ago
    Correct. I am personally tracking this issue and I hope to do something to improve the situation https://github.com/tomjaguarpaw/tilapia/issues/9 https://github.com/tomjaguarpaw/tilapia/issues/9
dllthomas 6y ago
I actually think the parent comment is sort of correct. If everyone was good (perfect?) about making sure that new versions of a package would work with code written against any old version of that package, then there would not have been cabal hell in really any of its forms. Of course, if this increased the number of forks, it would increase the times we need to convert between types provided by "different" libraries - which may or may not be a problem, but isn't "a Cabal problem". How it would actually work out in practice would depend a lot on how it shaped behavior; it sounds like srtjstjsj believes it went well for go, and I don't know enough to weigh in there in either direction.
- tome 6y ago
  I have no particular opinion on the main point of the comment. I just wanted to point out that the big problems with dependencies in the Haskell ecosystem, sometimes called "cabal hell", have not existed for at least the last few years (since the introduction of v2-style builds).
  - dllthomas 6y ago
    Yeah, worth surfacing!

by tome 6y ago

Cabal hell hasn't existed for quite a while. See https://cabal.readthedocs.io/en/3.4/nix-local-build-overview.html https://cabal.readthedocs.io/en/3.4/nix-local-build-overview...

srtjstjsj 6y ago

Nix doesn't solve the problem of incompatible versions in one binary. Nix only solves the problem of finding compatible versions if they exist. Cabal hell is more than one problem.

shirogane86x 6y ago
nix-style local builds (although the name is kinda bad) don't really have anything to do with nix, they're only the (admittedly bad) name for the new v2-* style commands (that now, at least as of cabal-3.0.0.0 and higher, are the default)
- tome 6y ago
  Correct. I am personally tracking this issue and I hope to do something to improve the situation https://github.com/tomjaguarpaw/tilapia/issues/9 https://github.com/tomjaguarpaw/tilapia/issues/9

dllthomas 6y ago

I actually think the parent comment is sort of correct. If everyone was good (perfect?) about making sure that new versions of a package would work with code written against any old version of that package, then there would not have been cabal hell in really any of its forms. Of course, if this increased the number of forks, it would increase the times we need to convert between types provided by "different" libraries - which may or may not be a problem, but isn't "a Cabal problem". How it would actually work out in practice would depend a lot on how it shaped behavior; it sounds like srtjstjsj believes it went well for go, and I don't know enough to weigh in there in either direction.

tome 6y ago
I have no particular opinion on the main point of the comment. I just wanted to point out that the big problems with dependencies in the Haskell ecosystem, sometimes called "cabal hell", have not existed for at least the last few years (since the introduction of v2-style builds).
- dllthomas 6y ago
  Yeah, worth surfacing!