We’re going in circles. I answered that already:
v2 is a workflow that’s fine for Haskellers who deal with projects anyway and have enough time and energy to work around cabal’s bad UX.
v1 without sandboxes doesn’t work well, so now we have the worst of both worlds.
When it comes to teaching, I now encourage the use of stack with the recommended GHC (9.4, lts-21.25) and package.yaml files. The latter are leaner than .cabal files and thus better suited to throw-away programming (such as solving exercises), also, they just follow standard YAML syntax.
I wonder whether people so fervently arguing in favor of sandboxes actually used them while they were available in Cabal. Because in my experience sandboxes were very annoying to manage, and the moment Stack arrived in 2015 it won the market overnight by obliterating them with “nix-style builds”, similar in spirit to what cabal v2-build introduced couple of years later.
Thank you both for specifying stack. (And that’s why my questions have been careful to specify cabal-install.) So the collective wisdom is newbies should be using stack?
I think we’re suggesting sandboxes are something suitable for newbies; not once you become a ‘production programmer’. I’m not expecting on this thread we’ll hear from any actual newbies, so feedback from those in teaching is our best proxy.
I think there are very different kinds of newbies, who cannot be served by the same means. If the goal is just to play with lambda calculus then, as you mentioned, there is little need for Cabal or Stack.
If the goal is to demonstrate how to solve real-world problems in a pure lazy language, Stack could be a better choice because of its swiss army knife approach, templates and hpack. Stack is very good at hiding implementation details: you don’t even need to know who GHC is (because Stack downloads and manages it transparently) or have any idea about Cabal files (indeed, YAML is enough).
However, if the goal is to eventually become proficient in Haskell product development then IMO starting with Cabal could be a better choice, precisely because it hides less details and forces you to learn basics of Haskell package ecosystem.
I’ve used sandboxes for a long time and so do other languages.
But let’s see what’s wrong with v2 first:
cabal install --lib is a re-introduction of cabal hell
It is so bad UX that, well, compiler/language developers have to ask how to use it.
It doesn’t support Makefile workflows or similar ones (such as copilot) properly.
I’m not suggesting v2 is useless. No. But we need to recognize that the current UX is insufficient.
You seem to assume there is a single “collective wisdom” and a single “production programmer”. It is hardly so. There are different users, working in different environments, for different reasons and with different goals. They will value different functionalities and some tools will fit their workflow better than others.
What does “newbies” even mean? A senior software engineer who has been mostly writing Go or C# and want to try writing Haskell, is that a newbies? A doctorate student in CS who has done some ocaml before, is that a newbie? What about an artist who is interested in using Haskell to add music or visuals to their project? These are not rhetorical question, I actually do not know what you idea of a “newbie” is.
Perhaps the misconception in backed in the title of the thread: you do not have to use cabal-install, it’s not inflicted on anyone. You do not even need to use sandboxes. If someone does not like any of those tools or workflows, that is fine.
Haskell has a diverse community of users, let’s make it our value.
How about…“someone not expecting to deal with this garbage in 2024” :
"Is cabal-install stable enough yet that GHC should be inflicting it on newbies?" - #43 by hasufell
Separate `cabal install --lib` into own command (cabal env) · Issue #6481 · haskell/cabal · GitHub
Ghc can't load a package, even when ghc-pkg listed it - #2 by tomjaguarpaw
Hidden package — Could not load — how to :set - #18 by igouy
Cannot satisfy -package-id X11-1.9.1-As84WI1VImVHquwEDPbrTE - #9 by jaror
…could cabal (the tool) actually be worse to use than git?
Thank you again Andrea. I was trying to make as few assumptions as possible, certainly nothing about how "production programmer"s want to work; nor that "senior software engineer"s (who are merely new to Haskell, not to development tooling) would be put off by starting with configuring a repository/sandbox rather than diving in to the new language.
Is chiefly who I had in mind as ‘newbie’. (That is, the learners, not the instructors 
) Although:
(Note this thread got spawned from one started by Simon.)
Perhaps SPJ should also count as ‘newbie’? Or let me turn that question round. When the front page for GHC says:
- GHC is a breeze to install using [
ghcup] or [Stack]
Who will find that a “breeze”? And should that page be be more careful in what expectations it’s setting? (As the above discussion goes on to note, most places you go from that front page try to persuade you to install the full toolset, not bare-bones GHC. Certainly nowhere repeats your “do not have to use cabal-install”.)
So when I can make some time, I’ll have a crack at setting up a newbie-style sandbox avoiding all of the above.
When I learned haskell two years ago, i initially only needed ghc, and installing it was indeed, “a breeze” (edit: with ghcup). I remember I preferred it than manually putting the binary in my PATH, plus, knowing that eventually i might need cabal/stack/hls, i also knew that with a few clicks they would be installed/removed with the ghcup TUI.
(this experience was as a newbie that only knew python at the time)
… by this definition we are all “newbies”. I am regular on cabal’s issue tracker so I am well aware of its short-comings. If you have a concrete proposal about what should be changed your are welcome to open an issue or a pull-request. We can work through the details there.
An analysis of the current tooling from the perspective of university students, teachers and lead-developers of GHC would be welcome 
You’ve basically described exactly what I want. I currently crudely approximate it by doing cabal install --lib of whatever packages I want to add, and after a while when that inevitably leads to errors, deleting ~/.ghc/x86_64-linux-9.10.1/environments/default and then doing cabal update followed by cabal install --lib of everything I had before plus the new one I want.
Could you elaborate on why you want that, specifically, as opposed to creating a .cabal file or adding cabal flags at the top of the source file (see cabal v2-repl)?
(I know there are a variety of good reasons, I’m just curious what yours are, particularly if they’re not reasons I already know about.)
It’s because I want a set of “ambient” packages to use in GHCi at any time without having a source file. For example, imagine you want to check if you’re remembering Gauss’s formula correctly. I find it convenient to just be able to type ghci from anywhere and then do import Test.QuickCheck and quickCheck $ \n -> n >= 0 ==> sum [1..n] === n * (n + 1) `div` 2.
Do v2 builds even look at the globally installed packages? I would expect them to be isolated.
In which case, your use-case would be the main one for cabal install --lib.
Thanks! How does that differ from having a directory with a .cabal file which contains in build-depends all the packages that you have “installed”? Then you can cd to that directory and use cabal repl to get GHCi with access to any of your “ambient” packages. I appreciate that this approach is slightly more “heavyweight”, but is there something else to it?
Yes and even worse: Special treatment of pre-installed packages by the solver · Issue #9669 · haskell/cabal · GitHub
Feels like a bug if v2 is billed as “Nix-style.”
v2 at least needs a --pure flag imo.
One reason is it feels less snappy. When comparing time ghci < /dev/null and time cabal repl --allow-newer < /dev/null, the latter usually takes 2-3x as long (only a few seconds, but still).