Cabal woe

[Simon Peyton Jones]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240710/e1ff6042/attachment.html>