Proposal: Don't read environment files by default

[Richard Eisenberg]

> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> 
> That being said, I'd be more interested to know the actual problems
> people are having

I've run into two problems. I don't expect others to run into these particular problems, as my workflows are likely different than others', but both of these bit me independently.

1. I use two different machines regularly. I keep my files in sync between them using Dropbox. Yet, the Haskell installations between are not identical. Even if the GHC version is the same, it's quite likely that some library, etc., has been installed at a different version on the two machines. (Sometimes, even the GHC is different.) I did some work on a project on machine 1; this produced an environment file. Then, machine 2's window happened to be in the project directory. I wanted to spin up GHCi to check the type of, e.g., traverse. But GHCi wouldn't launch! This is because machine 1's work produced the environment file which invisibly got copied to machine 2 (via Dropbox) and then GHCi tried to respect the environment file, even though I had no interest in interacting with that particular project at the moment. Frustration and confusion ensued.

2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones. This is because, usually, I'm compiling individual Haskell files and not projects. These Haskell files are snippets of code I look at in order to spot a GHC bug and files students email me seeking help on. I therefore like to build up a healthy set of libraries in my global package database so I can just test-drive these files, without worrying about managing dependencies. (It is true that I sometimes run into old-style "cabal hell", but I also accept that this is an unavoidable consequence of using the global package database. By the time this happens, a new GHC has been released anyway, and I use the outdated package database as an excuse to upgrade.)

  The actual relevant scenario is this: I open GHCi to load some files from a project, and I want to experiment with them. But I realize that I want to import a few modules from packages not otherwise used in the project (e.g., the 'extra' package) in order to conduct my experiments. But I can't do this, because the env file tells me I can't. Frustration and confusion ensued.

I have a better understanding of all this now -- and the knowledge to disable these features -- but this is how I came to dislike these env files. In both cases, it was because I wanted to interact with Haskell in a way that wasn't fully encapsulated within a project. Perhaps in a "real company", this wouldn't happen, but many Haskellers are not in real companies. :)

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/3bccc3fb/attachment.html>