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
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