Cabal woe

[Oleg Grenrus]

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

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. Matt's example highlights a strength:

cabal build -w ghc-9.6.2 (fails)
cabal build -w /path/to/devel/compiler (fails with error message)

As all the dependencies/build-info is written down in the .cabal file, 
trying out with different versions of GHC is trivial. It's not with 
environment files.

[1] https://github.com/phadej/cabal-extras/tree/master/cabal-env

On 9.7.2024 20.31, amindfv at mailbox.org wrote:
> On Tue, Jul 09, 2024 at 01:06:02PM -0400, amindfv--- via ghc-devs wrote:
>> [...]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) [...]
> Forgot to mention an additional common workflow issue: having pre-installed packages that come from non-{H,St}ackage sources. Just another source of friction, where typing g-h-c-i-ENTER was by far the easiest way to use the package.
>
> Tom
>