<div dir="ltr">Hi Richard,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 28, 2019 at 12:26 PM Richard Eisenberg <rae@richarde.dev> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>> wrote:</div><br class="gmail-m_-6355612608454464969Apple-interchange-newline"><div><span style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">That being said, I'd be more interested to know the actual problems</span><br style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">people are having</span></div></blockquote></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>  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.</div><div><br></div><div>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. :)</div><div><br></div><div>Richard</div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>