I agree and believe cabal v2-install has regressed from v1-install. My use case is I'm a hobbyist who writes small programs. I assume there are learners working outside a university class who are in a similar situation. Even experienced developers like Richard Eisenberg seem to agree, from https://github.com/haskell/cabal/issues/7832:

Further, we do think the use case Richard has outlined of a "nice universe for a playground" is an important one.

Great -- glad to hear it. Thank you.

However, experience has repeatedly shown that "do what I mean" algos in package management lead to frustrated and confused users, and while things should be as easy as possible, they should also be no easier than that, and finding that balance is not going to be simple.

I agree here, and have not thought about the specific of the algorithms above. But, there is an algorithm that is known to (mostly) work: what v1 did. That is, the universe expands only by user request, when that user asks to add a new package to their universe. At that point, cabal selects the most recent release of that package (or whatever version the user asked for). Then, cabal uses the same algorithm it usually uses to decide its dependencies. This worked for the lifetime of v1. But it only mostly worked, because of cabal-hell: that's why v2 exists! So there would be a potential pitfall in that users try to build an inconsistent universe, or they build a consistent universe that doesn't serve their actual needs. I'm not sure those pitfalls are avoidable... but maybe they could be mitigated with cabal destroy-universe which blows away the current universe, allowing the user to re-expand it from scratch. (In my own practice, a universe went stale at about the same rate as GHC released, and so I just moved to a new GHC when things got rough in the universe.)...


IMHO the current situation is a deterrent to beginners trying to learn Haskell. There is a huge amount to learn and adding cabal and stack etc can appear as a huge pain to them, particularly if they have used pip3, the Python  package manager. 

Also I'm surprised that Cabal isn't under the control of the Core Library committee, I think that would have made for a smoother transition from cabal v1 to v2

Thanks
George




On Tue, Jul 9, 2024 at 2:06 PM amindfv--- via ghc-devs <ghc-devs@haskell.org> wrote:
On Tue, Jul 09, 2024 at 05:07:07PM +0300, Oleg Grenrus wrote:
>
> On 9.7.2024 16.35, Simon Peyton Jones wrote:
> > Would it be possible to support the simple story above, as well?
>
> TL;DR the GHC developers (e.g. you, richard, sebastian) are virtually the
> only group of people who want to invoke GHC manually [...]

Genuinely curious, what makes you say this?

My only data is anecdata, but I've talked to quite a lot of people who miss the old days of `cabal install`-ing a package (particularly if it requires tweaking flags) and then having it at your fingertips whenever you run GHCi, `runghc`, or GHC. Some packages are so central to our workflows that it's almost like needing to `mkdir foo ; cd foo ; cabal init ; $EDITOR foo.cabal ; cabal repl` to get the Prelude.

Nobody misses the package conflicts that could come from long-term thoughtless default-global installation, but to say that almost nobody wants to invoke GHC manually seems like a major stretch. If we had a cleaner solution, I'm willing to bet a lot of people would drop the `cabal init` workflow for everyday tinkering like a hot potato.

Tom

P.S. I've built my own hacks on top of GHC environment files to recapture this way of working, but that's another story.

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs