On 05/13/2018 05:39 AM, Brandon Allbery wrote:
The whole point of them is to enable doing things that no tooling can sanely automate, enabling the environment from those builds to be available to do those things. Which is admittedly trying to do two incompatible things at once (propagate the build environment sometimes but not always, with no way to know which is intended); if you have a good answer for that one, I suspect many people would like to hear it.
I use nix-shell for choosing specific ghc environments, and undoubtedly a theoretical 'cabal shell' could work similarly. (In fact, Nix could probably produce a saner (shell) environment by using GHC environments, so the two solutions could converge.) Consider the following hypothetical session: $ cabal new-build # Creates .cabal.ghc.environment.arch-os-version, which is # non-default $ cabal shell # sets GHC_ENVIRONMENT to # $PWD/.cabal.ghc.environment.arch-os-version and spawns shell [cabal]$ ghc-pkg list ... (we see our customized environment) [cabal]$ exit $ cabal shell --run 'ghc-pkg list' ... (same output as previous) $ cabal shell --environment /path/to/ghc.environment [cabal]$ ghc-pkg list ... etc. Basically, "cabal shell" would be a wrapper over "GHC_ENVIRONMENT=/path $SHELL", but more friendly and with room for expansion.