Proposal: Don't read environment files by default

[Vanessa McHale]

I use cabal new-repl.

I actually kind of like having GHC environment files (maybe not as a
default) but they remind me of "vim turds" in that they end up littering
your projects.

Cheers,
Vanessa McHale

On 3/28/19 1:09 PM, Iavor Diatchki wrote:
> I am quite confused as to how people are using `ghci` without loading
> the environment files, at least in the context of cabal v2 (aka "new
> cabal").   When you run `ghci` on its own, unless you load an
> environment file, you would only have access to globally installed
> packages, which is almost never what you want.   What is the workflow
> that this proposal optimizes?
>
> The default behavior should be what's commonly useful and, in my
> experience, when I run GHCi in the context of a project, I pretty much
> always want it to load the environment associated with the project. 
>  It is incredibly useful when you are working on a project where there
> are multiple broken modules (e.g., during refactoring), and you want
> to fix them one at a time, in the order that makes sense to you.
>
> -Iavor
>
>
> On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson
> <spam at scientician.net <mailto:spam at scientician.net>> wrote:
>
>     On 28/03/2019 14.58, Oleg Grenrus wrote:
>     > There is. Add
>     >
>     >     write-ghc-environment-files: never
>     >
>     > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0
>     or later.
>     >
>
>     That doesn't really work if you actually want to be able to use both
>     ways of working, does it? That same thing applies to
>
>       export GHC_ENVIRONMENT=-
>
>     which someone else posted, but at least that can be done by tooling
>     before invoking ghc. It's odd to have to change a global setting to
>     avoid this. (However, thanks for the hints -- I'll be setting that
>     GHC_ENVIRONMENT from now on.)
>
>     +1 for changing the default.
>
>     It seems really weird to force other tooling to opt out when this
>     could
>     easily be solved by just having
>
>        cabal ghci
>        cabal ghc
>
>     commands which set up the environment properly and tell users to use
>     that if they want to use cabal's environment files. FWIW, I also see
>     e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
>     e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
>     something users should really be running unless they know what they're
>     doing *and* it should be as tooling-friendly as possible.
>
>     Regards,
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/c2f7a8b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/c2f7a8b6/attachment.sig>