On 2019-03-28 at 18:22:12 +0000, Duncan Coutts wrote:
The intention was to not force everyone to use "stack ghci" and "cabal ghci" all the time,
And it's important to note that those who *want* to be forced to "cabal ghci" all the time, can still subject themselves to that idiom by configuring their cabal installation accordingly. However, the point here is that there's also those of us who don't want to be denied the ability to *not* be forced to use that idiom, and instead use the CWD-sensitive idiom which nobody complains about when using Git or make. With GHC/Cabal as it stands we are ahead of other ecosystems as we're in the advantageous position to be able to support *more* workflows than other ecosystems can support. IMO we should embrace and leverage the flexibility rather than to trying to artificially limit our possibilities just because we're doing something different. I mean, with that attitude we can just stop trying to do anything new... ;-)
Perhaps the next best thing is a "cabal shell" feature, that enters a new system shell environment where ghc/ghci etc do pick up the project environment.
We already have this don't we? That's basically what `cabal v2-exec` does; but having to remember to invoke `cabal v2-exec bash` to enter a sub-shell is basically just a variant of "force everyone to use "cabal ghci" all the time where you have to go through cabal as a middleman even though you shouldn't have to. Don't get me wrong, it's good that we have `cabal v2-exec` as yet another tool in our toolbox and it can do a few extra things in that workflow and is useful for those who have opt-ed out of the automatic per-project CWD-driven-env-file management; *however*, it doesn't meet the needs for workflows of being able to invoke `ghci` without cursing like a sailor every time we end up in a useless GHCi session because we forgot to throw ourselves into a `cabal v2-exec` subshell in our n-th xterm (or [1]) even though other tooling like `make` or `git` which I'm used to as a developer does the right thing because they honor the common DWIM design principle/idiom for shell-oriented tooling... That being said, I'd be more interested to know the actual problems people are having and trying to address those without throwing the baby out with the bathwater, cause I think many of the problems are of the XY-problem variety here or simply because we did a terrible job at explaining, providing tutorials, or documenting how this feature works, what it is and what it isn't, how it can be used, and what cool new workflows are at our disposal with the upcoming major cabal 3.0 milestone... [1]: ...or even worse, being in the *wrong* subshell while you've already `cd`ed to a different project folder... imagine the amount of cursing you'd exhibit wondering for 5 minutes before you notice you're picking up another project's pkg env...