Proposal: Don't read environment files by default

[Bryan Richter]

I am +1 on not reading them by default. I dislike implicit configuration
(that's enough reason there), and it interacts poorly with other tools that
use ghc.

Like Richard Eisenberg, I also think of ghc as a low-level utility, but I
recognize that intuition is already wrong in various ways. (ghc is really
quite clever.) For me that's not reason enough to disable this.

The tight coupling with Cabal, however, seems unwise, and implicit
configuration seems like something from the 20th century.

If we want Nix-style builds, let's do them Nix style, and use a shell.

On Thu, Mar 28, 2019 at 3:50 PM Richard Eisenberg <rae at richarde.dev> wrote:

> I have spent quite a bit of time debugging this issue, being utterly
> surprised about the existence of these files. Furthermore, until today, I
> had been unable to find a way to turn the feature off. I now understand (
> https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an
> undocumented mechanism for doing so in GHC. It's still frustrating that
> there is no similar mechanism to globally (i.e., in ~/.cabal/config)
> disable these files in cabal.
>
> While I expect "project-based" tools to care about their directory (e.g.,
> git, cabal, stack), I would never expect a compiler (which is intended to
> be a low-level utility) to do so.
>
> Richard
>
> > On Mar 28, 2019, at 6:08 AM, Matthew Pickering <
> matthewtpickering at gmail.com> wrote:
> >
> > Hi all,
> >
> > Environment files have caused a large amount of pain for users because
> > they are read by default by GHC.
> >
> > For example: https://github.com/haskell/cabal/issues/4542
> >
> > Cabal developers have indicated that they are not going to stop
> > generating them by default despite the overwhelming user pressure.
> >
> > Therefore I propose that users should opt-in to using environment
> > files by having to explicitly pass a flag to enable the search
> > behavior.
> >
> > This will provide a much better user experience overall and will stop
> > tooling having to isolate itself from their existence.
> >
> > Cheers,
> >
> > Matt
> > _______________________________________________
> > ghc-devs mailing list
> > 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/fd2a6863/attachment.html>