Cabal woe

[amindfv at mailbox.org]

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