What killer feature exactly did cabal reimplement? Nix-style builds were proposed and discussed before stack happened afaik (but not implemented in time).
Cabal still refuses to implement the killer feature “install GHC without asking”. And I’m happy it doesn’t.
Support for stackage? Well, that’s maybe the only thing, but in its current form it’s not very usable and boils down to just “cabal downloads a cabal.config for you”. So that hasn’t been grandiously implemented either.
So I really don’t know what you mean. Maybe backpack support? Oh wait, it’s stack that doesn’t support this.
Kinda confused here.
Sorry, I totally skipped your comment about package.yaml, because that’s not a killer feature, it’s horrendous.
cabal-install and stack are not at different abstraction levels. They never were.
You’re maybe confusing the Setup.hs functionality with cabal-install?
But yes, I agree, cabal-install could also be structured differently. It’s poorly designed. There should be very clear separation between concerns. E.g.
- coming up with a build plan
- executing that build plan
This is implemented in some package managers as output → input pipelines. Every phase could have an output that the next tool consumes. Then you could build high abstraction cli around it more easily.
What is this principle called? People will get annoyed at me for bringing this up again, but let me try: it’s called unix principle.
That would also mean stack wouldn’t have to re-implement half of what is already in cabal-install.
And now to the question: which tool is more likely to ever achieve better such separation? It’s probably cabal-install, because stack firmly believes in batteries-include everything. It’s unlikely it will ever be modular. cabal-install is heading into that direction, very very slowly though. And maybe it’s not enough, but we can hope.