Snark aside, I think this is a very valid complaint and I’d love to see the Cabal docs reorganized to address it, regardless of whatever effort goes into designing and implementing an imperative interface on Cabal files.
2 Likes
I completely agree. Even as someone who knows what I’m doing, I find the Cabal docs quite hard to navigate. Perhaps I’ll have a think about how to reorganise them.
(Also, where is the best place to propose and discuss such documentation changes?)
3 Likes
what’s wrong with cabal add [pkg-name:][ctype:]component <dependencies>. For example
cabal add my-executable optparsecabal add my-library containerscabal add all text
I think, It is a good cli interface. The only (not) problem is that newcommers should learn that cabal uses components to create a package, something that (based on stack overflow questions) is not very well known.
yes but when you get the classic Module.Name belongs to hidden package xyz, consider adding it to your dependencies you push people to edit a file with very specific ad-hoc format. If that faliure was run cabal add component xyz people will be faced with something very common, which is running something in the console. And that is a very good improvement
Notice there are current efforts in this direction.
4 Likes
I might be missing something, but
hackage-cli add-bound DEPENDENCY VERSIONRANGE CABALFILE
works for years. This is a solved problem.
You don’t need any exact-printing infrastructure to add a dependency: it’s absolutely fine to have multiple build-depends sections in a single component.
5 Likes
Yes, but what’s missing in the ecosystem is something to tie this together.
Cabal via the compiler tells you to add a package, that it’s hidden, say. You have to then jump on to hackage to find out the latest version, try and remember PVP to make a range up. Or add it manually to the file, run gen-bounds, find a pencil, or copy and paste the result from the command line back into the file manually.
All of this information is already available to cabal to do the entire task, but there are all these human steps needed that feel like unnecessary points of manual labour and potential bug generators which feel like they could be easily automated.
4 Likes
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.
4 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.
11 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