Oleg (a cabal hero, btw, thank you Oleg) writes
`cabal-install` (and `stack` FWIW) don't want you to have any (implicit) state. That's not great for "real world projects".
But you necessarily have global state anyway! When I say `ghc -c Foo.hs` I get a particular Prelude, which in turn depends on a bunch of libraries. My mental model was simply that I can extend that global state, so that rather than only getting Prelude I get whatever libraries I install. Of course, if I go via cabal, all that global state would be ignored, because cabal would specify everything explicitly.
To put it another way, I can't figure out why
ghc -c Foo.hs -package this -package that
is any different from
cabal build
with a cabal file that has build-depends: this, that. Except that the former is a lot more convenient for quick compilations.
My impression these past few years is that it's desirable to have one or
more simple global states, accessible from e.g. ghci, and it's also
desirable to avoid package conflicts, and there's tension between these
needs. The above sentiment, though, seems to imply the former simply
isn't desirable to cabal devs in the first place.
I am not qualified to have a well-informed opinion about any of this. I'm just reporting one user's surprising (and disappointing) experience. I'm an outlier in some ways, yes, but here all I wanted to do (as a random GHC user) was compile Foo.hs with a package available, and was surprised that apparently this is no longer possible without creating an auxiliary cabal file and invoking ghc via cabal.
I wonder if there is an articulate writeup of Cabal's mental model. e.g. What is an environment file? Why can't my GHC find Prelude? If you invoke plain ghc, what packages does it "see"? Etc. The user manual is good once you have the basic framework in your head, but it's that "big picture" that I'm missing.
Thanks
Simon