> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel <hvrie...@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
