Skip to content
This repository

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

Closed
creswick opened this Issue · 4 comments

3 participants

Rogan Creswick Greg Weber j3h
Rogan 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.

Greg Weber

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.

Rogan 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.

Rogan 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
Something went wrong with that request. Please try again.