Use of GHC_PACKAGE_PATH prevents cabal updates

[zxq9]

Hub seems to set GHC_PACKAGE_PATH which makes updates to cabal fail. Cabal bootstraps itself and now checks for the presence of that environment variable and fails if it is set. Sort of a weird decision to make it fail instead of just silently ignore it, but that's how things seem to work.

I haven't found where hub is setting environment variables yet or how to sidestep this particular issue without upsetting the other great things hub does (or you'd have a patch) -- but this seems to be the problem.

A paste of a related failure: http://hpaste.org/78966

[cdornan]

I have only just seen this -- have been very busy.

I will look into this and fix over the Christmas break.

[Maybe I have set up GitHub badly but I rarely seem to get email with notifications of new tickets -- y'all, please feel free prod me over email directly after raising an issue here].

[zxq9]

Wound up travelling right after I opened this. Just tested again today and it looks resolved. I suppose I'll remain happily ignorant of the underlying cause for now.

[cdornan]

thanks very much for the update -- I have been working on hub, made some fixes and released 1.1.1 a few days ago -- but for EL6 only. Did you update to 1.1.1? (I will update for the other platforms and make an announcement fairly soon.)

This is tricky, because I set GHC_PACKAGE_PATH when invoking any of the ghc utilities. I also do it for cabal because it also invokes these utilities. Of course for cabal itself I set --package-db to the user package DB to tell it where to install its modules. If it truly throws a hissy fit when it sees GHC_PACKAGE_PATH set then that could cause problems for us.

Hoever, if the problem is just with building cabal then I that is a bit delicate. The whole bundle is supposed to be complete with each platform and cabal being matched with the appropriate version of cabal. If you need to build your own cabal and are running into problems like this then I suggest setting up a special environment with the native tools (at whichever version you want) placed on the path ahead of the /usr/bin ones that indirect through hub. For example, if you want to use the ghc-7.4.1 tools then that would be /usr/hs/ghc/7.4.1/bin (and these will use whatever is in the default package DB under ~/.ghc of course, unless you set up GHC_PACKAGE_PATH.) If you put /usr/hs/tools at the fron of your path then you will get cabal 0.10.2 fo 'cabal' and 0.14.0 for 'cabal-0.14.0'.

Maybe we could provide some simple scripts for setting up these environments for the (rare I hope) occasions that folks need to run the raw tools.

[I am opening this issue again for a while to raise awareness of the issue and encourage discussion.]

[zxq9]

It looks like that particular environment variable is not just deprecated or obsolete, its actually cancer. I'm not sure how far back --package-db is valid, but Cabal >= 0.16 doesn't just ignore or fail to respect GHC_PACKAGE_PATH, it actually tests for and then deliberately fails if it is set at all (silently ignoring it in the presence of --package-db isn't good enough for someone, obviously). Hub will need to test the Cabal version whenever this applies and behave accordingly.

Other's seem to have run into this problem around October last year. Here's an example: https://github.com/Paczesiowa/hsenv/pull/35

Irritating -- stupid, even -- but I suppose that is one way of forcing everyone to modernize with the platform. On the other hand hub's whole purpose is to prevent people from being forced to modernize when they don't want to, so I don't think there is any way of avoiding dealing with this directly since it is an environment enforcement issue not just a change internal to the way GHC/Cabal/Haskell work.

I still don't get what the point of enforcing this change is, though, since GHC doesn't care what unused variables are set in the environment.

[cdornan]

As far as I can tell Hub does work fine for nearly all cases. GHC_PACKAGE_PATH isn't obsolete but a critical interface to the GHC tools, which cabal invokes to compile Haskell. --package-db doen't contain enough information, only the package DB where cabal should place the code, so we must set GHC_PACKAGE_PATH in hub when invoking cabal so that when cabal call the GHC tools they know where to find the global package database as well as the user package database (which we pass to cabal via --package-db).

Updating cabal may cause some problems. If so then I recommend setting up an environment with all of the tools directly on the path (see the above comment).

However, if you installed hub by just installing RPMs from the JustHub repository then that is the best channel for getting updates to Cabal because the distro is managing the integration of all of the tools. If there is a new version of Cabal that you need and its is not in the JustHub distro then please drop me a line. I like to know about what folks want and will be able to give you an indication of when it will be added. Of course if you really need it now then it shouldn't be too difficult to build (so far I myself have not encountered complications using hub to build cabal after all).

If cabal is telling you that there is a new version of cabal and nagging you to update then I would seriously ignore any such suggestions. I am not aware of anything that needs a later cabal than provided with the latest platform. It is much more likely that you will break things with an update. (Note that the cabal download page is telling you to download cabal-install 0.14.0 even though the latest is 0.16.0.3.

I will be happy to provide an extra rpm with cabal-install 0.16.3 which you could selectively use with your hubs (by a simple edit to the hub xml file).