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.
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.
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.
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?
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.
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.
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.
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.
Out of curiosity, how did cabal install / cabal install --lib blow up with LPWFP?
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.
Yeah this can be improved. For instance, if I pass --help to my tasty test suite with
cabal test --test-options='--help'
I get no help. Now, it is in the log file that for printed. Because --help prints to stdout.
The help itself answers the question of how to run specific tests at least.
This is technically cabal’s fault, but at the same time, suppressing stdout for tests that exit 0 is a sensible default. Maybe it’s on tasty to output help to stderr and defy convention? I’m not sure.
You can
cabal run tests -- --help
and it works fine.
So, it’s 100% possible I’m doing something to screw this up, and if so: my apologies, and hurray for learning something new.
The following is the process outlined in the appendix. He first offers global lib instructions, then this for local. Similar sort of thing, really, just changes where the config file gets stored. He recommends renaming the config file and installing all the libraries you’re interested in at once if you want more than one. The example he gives for that is: cabal install --lib gnuplot gloss cyclotomic --package-env . for local, cabal install --lib gnuplot gloss cyclotomic for global. (See page 585 of the print edition.)
andrew@ajf-mbp temp % ghci
GHCi, version 9.6.3: https://www.haskell.org/ghc/ :? for help
ghci> 2 + 2
4
ghci> :q
Leaving GHCi.
andrew@ajf-mbp temp % cabal install --lib gnuplot --package-env .
Resolving dependencies...
andrew@ajf-mbp temp % ghci
Loaded package environment from /Users/andrew/dev/temp/.ghc.environment.aarch64-darwin-9.6.3
GHCi, version 9.6.3: https://www.haskell.org/ghc/ :? for help
ghci> :m Graphics.Gnuplot.Simple
ghci> :t plotFunc
plotFunc
:: (Graphics.Gnuplot.Value.Atom.C a,
Graphics.Gnuplot.Value.Tuple.C a) =>
[Attribute] -> [a] -> (a -> a) -> ghc-prim:GHC.Types.IO ()
ghci> 2 + 2
<interactive>:3:3: error: [GHC-88464]
Variable not in scope: (+) :: t0 -> t1 -> t
ghci> :q
Leaving GHCi.
andrew@ajf-mbp temp % cat .ghc.environment.aarch64-darwin-9.6.3
clear-package-db
global-package-db
package-db /Users/andrew/.cabal/store/ghc-9.6.3/package.db
package-id gnplt-0.5.7-1f7a223d
So, base doesn’t get loaded, which is easy enough to fix. But, I feel like that’s something you don’t really want to expose a complete beginner to. I’m a bit puzzled as to what the author thought ought to happen here, which is why I’m assuming I’m doing something dumb myself. 
-e- It was the very first post in this thread that prompted me to go look up what LPWFP suggested.
This is a very important common use case that i added to [Initiative] Improve Cabal documentation structure to become more beginner-friendly · Issue #9214 · haskell/cabal · GitHub to write a Cabal guide for (testing setup and running in general).
This was a bug in the last version of cabal which is going to be fixed with the coming release.
Really? That’s good to know. Thanks. Although, I would have sworn this was what happened the last time I ventured into install --lib territory over a year ago.
Cool, ta!
Challenge accepted I spent in total 2.5 hours this evening writing GitHub - Bodigrim/cabal-add. Would you like to try and break it?
$ cabal-add --help
Usage: cabal-add [-f|--cabal-file FILE] [-c|--component ARG] DEP
Extend build-depends from the command line
Available options:
-f,--cabal-file FILE Cabal file to edit in place (.cabal file in the
current folder, if omitted)
-c,--component ARG Package component to update (the main library, if
omitted)
DEP Package to add to build-depends section
-h,--help Show this help text
Thanks very much! When I have time, I will try my best to do so…
(That being said, I’m very busy writing my thesis right now, so I might not get to it soon. This is also why the templating tool I promised earlier isn’t ready yet.)
Ah this is amazing! I will try this out tomorrow and report any issues if I find anything. Thanks Bodigrim!