Agreed, but my point is that there is no technical challenge to implement cabal add (or a standalone cabal-add executable), which would be the first step in the direction. This can be done today.
4 Likes
I don’t know so much… of the six reported issues for hackage-cli, one is that add-bound results in a malformed cabal file. This is exactly the kind of issue I would expect from a more ‘hacky’ solution like this, which works in most cases but fails when something unexpected comes up.
5 Likes
I’m starting with the documentation for Cabal as described here but i intend to separate guides from references, and then to make these guides more beginner-friendly for some widely used packages, probably aeson, process, yesod, persistent. Until then the hosting issue may have been solved by @Kleidukos in Haddock.
7 Likes
Wonderful! Would you be willing to post occasional updates here on Discourse so we can follow along? You are undertaking a valuable project 
4 Likes
Convenient as it is, cabal install delenda est.
Just remove it already, and put a long sob story about generations of newbies getting their feet blown off or went python/node after trying to use it.
Add install-exe or something like that that would deal with the safe-ish part of it. And go to the drawing board for sane and ergonomic package management design. Enough is enough.
3 Likes
cabal install isn’t the problem, the problem is --lib, which the error messages tell you to use.
According to posters on this thread, even --lib is safe to use under modern v2 / nix-style builds, because cabal-install (the executable) creates a dummy package env per build.
However, as I keep on trying to emphasize there, --lib is a general disaster. The only valid use, imo, is to create a package environment file by cabal install base --lib, and then it’s still footgunny once the package environment file exists (because apparently you’ll end up with different versions of the same package with the same identifier; cabal itself doesn’t care, but ghci / ghc do).
What I’d suggest would be:
- cabal install --lib is dead; it’s marked experimental and I’m unsure as to anyone wants to finish the experiment?
- cabal pkgenv and cabal pkgenv globalclean comes in with an unsafe warning.
Long-term, I hear some people working cabal seem interested in managing the global package env, but I guess it’s more a question of speculation, since that requires labor and effort, and… ummm…
Talk talk talk.
Cabal needs a full time dev. Funded by the Haskell Foundation. It has become a bottleneck for the tooling experience.
10 Likes
cabal is almost 20 years old. Any tool with such a history — and with a plethora of contributors, and main developers — will have some warts and a good amount of legacy baggage to support.
Things have moved a great deal in the past — remember when we used sandboxes? — and are moving now.
8 Likes
There’s code by one Sven Panne that dates back to 2002, I believe, so Cabal is old enough to drink in the United States… no, I think that’s GetOpt in cabal that’s a fork of GetOpt from GHC.Base.
That said, aren’t you still looking for additional maintainers? That’s a different way to interpret hasufell’s first line, that instead of pure talk and talking about what can be done to improve Cabal, people actually sign up to help keep the thing running.
Yes, I remember when Oleg was sole cabal maintainer and burned out. I also remember that things moved forward when the HF CTO was involved in cabal development.
There are a lot of things that need to be done and some of them require significant implementation work and others careful coordination and someone to keep a close eye on user experience.
Relying purely on volunteer efforts for something as crucial as cabal seems inappropriate to me.
2 Likes
However, as I keep on trying to emphasize there, --lib is a general disaster. The only valid use, imo, is to create a package environment file by cabal install base --lib, and then it’s still footgunny once the package environment file exists (because apparently you’ll end up with different versions of the same package with the same identifier; cabal itself doesn’t care, but ghci / ghc do).
This last issue was fixed in the latest release. The ergonomics still aren’t great but A) base is there by default but B) other bootlibs aren’t and C) installing something that matches something already there will now trigger an option to force override, just like old v1 behavior.
Its ergonomically tricky just like v1-install was tricky, but we’re open to suggestions for improvements and PRs implementing them – its getting there… just slowly.
2 Likes
I’m certainly not seeing signs of this. On the contrary, there is a steady trickle of cabal install (–lib or otherwise) problem reports with people proceeding then to post “haskell is hard” / “tooling is terrible”.
cabal install delenda est.
1 Like
Can you post some examples of cabal install blowing up in people’s faces?
I know on Windows, at least, many repos simply don’t work. If it’s Windows related, you’re just moving the problem from cabal install to cabal build or cabal run.
Can you post some examples of
cabal installblowing up in people’s faces?
3 Likes
The problem is that many textbooks, including Simon Marlow’s Parallel and Concurrent Programming In Haskell, include cabal install instructions, when the behavior has utterly changed (despite @sclv, I still consider --lib smelly because there’s no corresponding uninstall).
The practical issue seems to be, that cabal install is easy to get wrong, then users, including myself in the past, go on to pester channels and maintainers.
Anyways, I don’t think I have anything insightful to add further on this topic. I’m the rare user happy with cabal install, but I’m willing to lose my workflow (ghci --package foo when messing around) if it makes everyone else happier.
1 Like
I did a big collection of those somewhere on r/haskell a year ago or so, got some karma, but the trail of tears went on anyway.
2 Likes
And this is exactly why cabal install delenda* est.
We can put it back when its handling is fixed. Before that - let it be known that we made a big screw up here and keep people away. “Crime scene, do not cross.”
* By replacing its handler with the notice herding users to a good project management tutorial.
1 Like
I noticed the new Learn Physics with FP (Haskell) (Walck, December 2022) liberally suggests cabal install and cabal install --lib. And, I thought: ‘oh, maybe that’s ok now, or at least with this.’
Spoiler? It’s not.
1 Like
Out of curiosity, how did cabal install / cabal install --lib blow up with LPWFP?
1 Like
I just want to chip in because I ran into 1 more example.
I find that I spend more time fighting certain things which I’ve never had to think much about in other language ecosystems.
Specifically how to run a specific test. I leave a codebase for a few months, and I have to remember this again, which usually means googling around, and some old stackover pages.
But I think things like running a test and running a specific test should not be something you spend considerable time figuring out.
4 Likes