Path parsing changed in recent cabal/cabal-install's #2

Closed
creswick opened this Issue Jan 3, 2011 · 4 comments

3 participants

@creswick
Owner

The cabal path parsing changed in recent Cabal or cabal-installs, so quoted paths are not parsed as they were previously. Attempting to use cabal-dev on an existing sandbox, with a newer cabal-install on the path (built with Cabal-1.10) results in errors like this:

$ cabal-dev install
Resolving dependencies...
Configuring VersionSpaces-0.0...
cabal: expected an absolute directory name for --prefix:
"/home/creswick/development/havsa/cabal-dev/"
cabal: Error: some packages failed to install:
VersionSpaces-0.0 failed during the configure step. The exception was:
ExitFailure 1
$ cabal --version
cabal-install version 0.9.5
using version 1.10.0.0 of the Cabal library 

The error is slightly different if there is no cabal-dev sandbox:
$ cabal-dev install
Resolving dependencies...
Configuring mtl-1.1.1.1...
cabal: expected an absolute directory name for --prefix:
"/home/creswick/development/havsa/cabal-dev/"
cabal: Error: some packages failed to install:
VersionSpaces-0.0 depends on mtl-1.1.1.1 which failed to install.
logict-0.4.1 depends on mtl-1.1.1.1 which failed to install.
mtl-1.1.1.1 failed during the configure step. The exception was:
ExitFailure 1
(although, the difference is minor -- it fails sooner.)

John Millikin suggested this fix:
I ended up fixing this by changing line 137 of RewriteCabalConfig.hs
from @eExpand = fmap show . ePath@ to @eExpand = ePath@, matching the
definition on line 118.
This breaks some behavior with older versions of Cabal/cabal-install (and triggers a test failure), so it would be nice to find a more general solution.

@gregwebs

can this be fixed using Cabal's MIN_VERSION macros with John Millikin's suggestions?

#ifdef MIN_VERSION_cabal(1,10,0)
  eExpand = ePath
#else
  eExpand = fmap show . ePath
#endif
@j3h
Collaborator

The problem with that suggested solution is that the version that will be checked is the version of Cabal that cabal-dev was compiled with, and if that is not the same as the version that cabal-install was compiled with, it will still break. We really ought to check for the version of Cabal that cabal-install was built with, which we can get at by parsing the output of cabal --version. It's a little more complicated than the #ifdef, but not too bad.

@creswick
Owner

Unfortunately, I don't believe this bug can be addressed at compile time.

The MIN_VERSION macro is a viable workaround but I don't think it will serve as a long-term solution, since the problem appears to be caused by certain versions of the run-time tools.

This bug seems to arise when the cabal-install binary that cabal-dev invokes uses a Cabal library version with a newer config file parser/serializer (which is more consistent than the previous parser/serializer). Since cabal-dev simply uses the cabal-install on your PATH, this bug may or may not be present on any given run of cabal-dev, depending on which cabal-install is found on the PATH.

One solution is to parse the output of cabal --version to determine which version of Cabal is in use and alter the cabal-dev behavior accordingly.

@creswick
Owner

This has been fixed in cabal-dev-0.7.4.0!

cabal-dev now performs a runtime check to determine which version of Cabal was used to build the cabal-install binary that cabal-dev invokes.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment