Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

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