Fay typechecking does not work from a sandbox

[snoyberg]

In order to reproduce, unregister fay from your user package database and install via cabal-dev install fay. Then trying to compile anything with fay results in:

$ ./cabal-dev/bin/fay test.hs fay: <command line>: cannot satisfy -package fay
    (use -v for more information)

I ran into a similar issue with doctest; the solution we agreed on in sol/doctest#39 was to pass in an extra HASKELL_PACKAGE_SANDBOX environment variable. We could theoretically use GHC_PACKAGE_PATH instead, but that would cause issues with cabal-install.

[chrisdone]

Indeed, we're aware of this problem but up until now it seemed I was the only one who installed just with cabal-dev to be bothered by it (I tend to use --no-ghc when invoking outside of Cabal). Passing in an environment variable for the package-conf sounds good.

[snoyberg]

This isn't affecting me in any major way, I just thought if I'm already working on a related solution I may as well file the issue. I think I'll open an issue with cabal-dev to set the HASKELL_PACKAGE_SANDBOX environment variable as well.

[snoyberg]

Whoa, that was fast. Thanks!

[sol]

@chrisdone GHC 7.6.1 deprecated the use of package-conf. I just ran into this with doctest.

I use:

#if __GLASGOW_HASKELL__ >= 706
ghcPackageDbFlag = "-package-db"
#else
ghcPackageDbFlag = "-package-conf"
#endif

[snoyberg]

Just to be pedantic, this may not be sufficient for Fay. Fay is calling GHC over the command line, which might be a different version of GHC it was compiled with. I think the technically correct solution would be to parse the output of ghc --version. I'm not sure if it's worth it though, this snippet would probably work the vast majority of the time.

[sol]

Ah, ok. In that case I would not use that code. With doctest the situation is different. It uses ghc-paths, so it always uses the ghc it was compiled with.

[sol]

@snoyberg Aiming for correctness is not pedantic :)

[chrisdone]

Thanks, @sol.

[sol]

@chrisdone The reason that doctest uses ghc-paths instead of the ghc that is on the PATH is that doctest not only uses the ghc executable but also the GHC API, and the GHC API version has to match the ghc executable version.

I have no idea what is appropriate for fay, but for doctest I'd love to use the ghc that is on the PATH if I could. There are things that can go wrong if you "compile in" the path to ghc (e.g when the user updates his GHC installation). For doctest this is a frequent source of user frustration.

So parsing ghc --version (as @snoyberg suggested) may be more robust.

[chrisdone]

Honestly, I always use fay with --no-ghc, so I don't actually use this feature. Maybe @bergmark or @cdsmith can decide what's preferable for them. I don't feel like doing any more on an issue I don't care about.

[snoyberg]

Pull request #175 checks the GHC version from the command line.