hsenv emacs mode sets GHC_PACKAGE_PATH instead of PACKAGE_DB_FOR_CABAL and PACKAGE_DB_FOR_GHC about hsenv

[dudebout]

This is a known shortcoming but not a very bad one. GHC_PACKAGE_PATH used to be working for everything. With cabal 1.16, this variable became forbidden for cabal while still working for ghc. This lead to a "complete rewrite" of hsenv. In particular, there are mutiple tests for the different versions of ghc etc.

Unfortunately, the emacs module does not use an hsenv binary. It is in effect a complete reimplementation in emacs lisp of <dir>/.hsenv/bin/activate. To do it properly it would have to mimick the tests for all the ghc versions.

As @tmhedberg mentioned in other issues, we do not know if hsenv will be needed much longer as cabal talks about doing sandboxing itsels. Therefore, I am not really willing to spend that much time rewriting hsenv.el.

On the bright side, everything works inside of emacs except for cabal with version greater than 1.16. So the only thing you cannot do easily is install packages. IMHO, this is an event rare enought that I can drop to a shell and use activate instead of relying on emacs for it.

Feel free to write a pull request to fix it.

[tmhedberg]

Just to reinforce what @dudebout said, the GHC_PACKAGE_PATH variable has been quite a thorn in our collective sides since it was "forcibly deprecated" in Cabal. Older versions of Cabal (which are unfortunately not old enough to have fallen completely out of use) require it to be set in order to work properly with hsenv, while newer versions (as you have seen) will refuse to run if it is set. So anything hsenv-related that invokes Cabal must be able to configure itself differently depending on which version of Cabal is available; there is no mechanism that works correctly for all versions of Cabal. This means that additional logic must be added in various places in order to ensure portability across multiple versions.

In any case, a pull request would indeed be welcomed. :)

[lambdageek]

Thanks. Makes sense. I'll try to spend a couple hours with Elisp this weekend and send a pull request if I get anywhere.

[nominolo]

Actually, not being able to use Cabal from within Emacs is a huge issue if you're trying to use something IDE-like (I'm building something like that) from within Emacs. Fortunately, #27 fixes this.

[dudebout]

huge is a little strong ;-)

[nominolo]

Well, the correct phrasing would be "completely unusable". Since Scion (WIP) automatically configures a package using Cabal and thus it would break for every single package.

[tmhedberg]

I believe this is now fixed thanks to #27. Can any Emacs users confirm this?

[nominolo]

Confirmed fixed.

[tmhedberg]

Thanks.