Proposal: Don't read environment files by default

[Iavor Diatchki]

Hi Richard,

For use case 1)  we should probably make GHCi be more robust, and make it
notice that an environment file has become unusable, say so, and ignore it,
rather than refusing to work.  It is a bit of an odd way to synchronize
build artifacts though.

For 2), I like global databases too, and I think that this system is very
compatible with it---you can think of the "global" environment as a default
project that GHCi uses when there is no other project around.  I believe
something like that is already being developed.  In the mean-time, however,
I've just been using one "sand-box" cabal project that has just a cabal
file, and no source files---when I want to try stuff out, I just go to that
project and fire up `ghci`.  It avoids cabal hell as you can easily control
the versions of the libraries you need, if you care.  It is also cool, in
that you can put it on github, and be able to easily recreate the same
environment on different machines.  And having used that for a while, I've
noticed that perhaps I don't really want a global project, as I've evolved
a couple of different "sand-boxes" for different topics that I commonly
play around with.

As for your relevant scenario:  couldn't you just add the packages you want
to use to your cabal file and ask it to build them for you?  Then you'd
know what version of the package you are actually experimenting with.  I
haven't actually run into this issue much, so I can't recall what GHCi says
if you try to use a module from a package that is not part of the current
context, but it sounds like we may want to improve its message, if the
current situation is confusing.




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

>
>
> 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
> _______________________________________________
> 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/20190329/d2b364e6/attachment.html>