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. Oleg mentioned https://github.com/haskell/cabal/issues/6481, and Julian drew my attention to https://github.com/haskell/cabal/issues/10098. 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 On Tue, 9 Jul 2024 at 20:06, amindfv--- via ghc-devs <ghc-devs@haskell.org> wrote: > On Tue, Jul 09, 2024 at 08:50:18PM +0300, Oleg Grenrus wrote: > > cabal-install has various means to address that too. You can have > `packages: > > /anywhere/onyourdisk` or `packages: http://somewhere.else/tar.gz in your > > cabal.project. Or you can have `source-repository-packages` for accessing > > remote git repositories. Or you can setup > https://cabal.readthedocs.io/en/stable/config.html#local-no-index-repositories > > for a bit more permanent and reusable solution. > > > > cabal-install has ways to approach those problems *without having a > > stateful/implicit setup*. And the workflow is the same as usual workflow > > with packages and projects. In fact, real work projects do use > > source-repository-packages (and sometimes in project vendored `.tar.gz` > > source distributions). > > Yep, I'm aware (and in fact have used `source-repository-package` on > business-critical work projects. I appreciate its existence!). > > However, I'm specifically trying to get to the bottom of the sentiment > that "the GHC developers (e.g. you, richard, sebastian) are virtually the > only group of people who want to invoke GHC manually." > > 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. > > > An anecdote from my side: I wrote`cabal-env` [1] for myself somewhat five > > years ago. I don't think I have used in the last two years. The package > > workflow is often better. > > I've used it! My current work is another attempt to tackle a similar > use-case. I disagree (strongly) that for my needs the package workflow is > better. > > Cheers, > Tom > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
