cabal(-the-library) already is the library that provides the commonalities.
Apparently it isn’t, being stuck since 2018. And stuff like this is eroding trust in cabal-install 
Where did you read it’s stuck? No one has worked on it. It’s an open source project… feel free to provide a PR.
Looks far from small to me.
As a ghcid user, I am not even sure it belongs to cabal. “Do one thing, do it well” and so on.
But if you use cabal to build your project, only cabal knows which files changes to should trigger a rebuild, so it seems it’s cabal’s responsibility to provide this to consumers.
(That said, I am happy with ghcid --command="cabal repl" so perhaps the precise set of critical files is not necessary in practice.)
I meant the domain of keeping up with where we are at with the upgrade cycles.
It seems to me you really haven’t used cabal in a long time.
I am a daily cabal user. cabal gen-bounds, common stanzas, cabal-fmt and I are on friendly terms. I use stack for the stack new templates, and, yes, for file monitor duties. I usually lock it down if I’m gaming and run out of room on my laptop. hls stability is my number one need for development.
I like to benchmark my libraries against lts and nightly resolvers, and maintain a stack.yaml. It’s an early-warning system for when a dependency gets brittle, or when upgrades will take time, so projects may as well wait it out a bit.
But if we ask ourselves the question “which tool to fix?” then I think cabal is the very clear answer.
I’m pretty certain the stack team would readily agree with this. It is described as feature complete - there is nothing to fix. Please go ahead and fix cabal.
You must be joking: Issues · commercialhaskell/stack · GitHub
Lack of backpack support and lack of a constraint solver are probably the biggest points why it has never obsoleted cabal.
The point here is that cabal devs are actively working towards closing the last gaps: https://github.com/haskell/cabal/issues/7556
Stack will probably never include a constraint solver.
Well, Snoyman says this in the blog post quoted above:
I decided that it was time to call out Stack as needing motivated maintainers, or to see it sit in a feature complete, non-evolving state.
The repeated complaint about Stack lacking a constraint solver seems odd to me - if the solver is in cabal (the program) then it’s in the wrong place: it should be in Cabal (the library) which can then be used by Stack.
As for that list of issues: if stack (the program) does rely on Cabal (the library), how many of those issues are due to issues with Cabal?
I think one must define one’s terms here. To one person, “feature complete” may mean “will not gain any more features” while to another it may me “would not benefit from gaining more features”.
It is: cabal/cabal-install-solver at master · haskell/cabal · GitHub
That will probably never happen, because afaik, stack maintainers are against the idea of using a solver.
I think the terms are simple to define: can one tool cover the use cases of the other?
The answer for cabal is: yes.
The answer for stack is: no (at least there’s no indication that it’s going anywhere in that direction, because apparently it’s “feature complete”).
To be clear, I’m not saying the terms need definition, or there is a benefit in defining the term, per se, I am saying that it’s helpful if discussion participants explain briefly how they are using a term, where there is potential for confusion.
Using the search term haskell stack constraint solver :
-
https://github.com/commercialhaskell/stack/issues/2888
(again due to a change in Cabal) -
Why Not Both?. Build Haskell projects with either… | by fommil | Medium
…or are you referring to a different variety of constraint?
Aright, so Stack seems to have fallen into disrepair (even the documentation is now out of date), but it’s still being actively used. So now imagine if the situation was reversed: Cabal split away from Stack acrimoniously all those years ago and now Cabal was the laggard.
Given that alternate reality, how would the Cabal users here react to the possibility that they would have to return to using Stack?
Considering that even Rust looks very much like having a second compiler by year’s end, the potential loss of another segment of the Haskell community is absolutely not a cause for celebration - that would make us “look small” in addition to being smaller.
Reading this and that other thread concerning stack/cabal indeed feels like something you would not want
to get involved as a new user and to be honest it makes me a bit anxious and sad.
I think I can understand most perspectives and I’m surely not in a position to make any real contribution to the discussion but please allow me to give my opinion as a Haskell user.
For me the situation is like this:
- main use-case for stack: Stackage
- really like to use packages.yaml instead of .cabal
- not really using other (still maintained?) features like docker/nix integration
From what I read here there is or will be a way to easily(?) use Stackage with “just” cabal and there seems to be a tool/way to use the .yaml approach too (would be fine even if not).
Assuming the situation is really that the main-maintainer of stack more or less wants to pass the project on but there seems to be none willing to do so then maybe we can find a way to communicate this clearly to both stack and cabal users.
I think if we could have a document telling former stack users on how to migrate to cabal and how to setup projects, … (IMHO it’s safe to assume that there are Haskell users out there that started with stack and did not really have much cabal interactions) - then I’d suspect that most normal users (without more skin in the game aside from using stack) would be happy to move forward and migrate to cabal (I surely would be and I guess that’s what I will do anyway).
@tonyday567 so to be clear, getting a list of killer stack features from people like you is exactly the first step. It would be bad to deprecate Stack before all of those are also implemented in Cabal.
@CarstenK thanks that list also makes sense to me.
I do sometmes joke, often in a futile attempt to lighten the tone when talking about something that matters deeply to all of us, but not here.
When the lead developer on a project, whether retired with distinction or in caretaker mode says ‘feature complete’ I tend to take their word on it.
Stack has never been a project with a design goal to obsolete cabal. Who would want that millstone? The feature set has always involved papering over the worst cracks in the cabal ecosystem.
Stack was born in a realisation that cabal would never be obsoleted, but may fall short in getting the support it needs, given its deep embedding in the ghc project and the condition of its codebase. The thought back in the day was to try and bring some productivity and sanity to library development, by paving the release uplift with a bit of social grace beyond constraint solving. I might be old fashioned, but that remains my use case.
stack users are well aware that they are also cabal users. It doesn’t take long before you know stack exec cabal -- --do-cabal-stuff. If you run into a (perhaps) undocumented corner case in cabal, odds are the solution appears as a stack command or usage example found in a quick search in stack issues and docs.
Please go ahead and fix cabal.
Apologies for the tone but I really meant it. I have high regard for your work on GHCUp, and would love to see a similar approach to the cabal user experience and api.
PS. A reliable source tells me the cabal codebase is one sixth the size of ghc.