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, amin...@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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
