Cabal cross-matches versions

[ndmitchell]

On Windows, with the MinGHC install, with cabal --version:

cabal-install version 1.20.0.3
using version 1.20.0.1 of the Cabal library

Picking the ghcid project (just because it was handy), when I do cabal install --verbose I see:

Waiting for install task to finish...
creating dist\setup
"C:\Program Files (x86)\MinGHC-7.8.3\ghc-7.8.3\bin\ghc.exe" "--make" "-odir" ".\dist\setup" "-hidir" ".\dist\setup" "-i" "-i." "-package-id" "Cabal-1.18.1.3-4219b3f170da38844ae813fba0d31349" ".\dist\setup\setup.hs" "-o" ".\dist\setup\setup.exe" "-threaded"
creating C:\Users\ndmit_000\AppData\Roaming\cabal\setup-exe-cache
Installing executable .\dist\setup\setup.exe to
C:\Users\ndmit_000\AppData\Roaming\cabal\setup-exe-cache\setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe

So because ghc-pkg list gives Cabal-1.18.1.3, then cabal has decided to pick that. It gets even more confusing when I do:

$ cabal haddock
cabal: You need to re-run the 'configure' command. The version of Cabal being
used has changed (was Cabal-1.18.1.3, now Cabal-1.20.0.1).

So while cabal install compiles a simple setup binary (which seems unnecessary, given its simple style), the haddock doesn't use that simple binary, so you get a version clash. It seems if I then do cabal configure that configures with 1.20, but a cabal install then has to reconfigure it.

In addition, I think because my location of Haddock has a space in it, Cabal-1.18 fails to install the docs but Cabal-1.20 succeeds.

[23Skidoo]

This happens because of the difference between the internal and external setup methods. Normally for build-type: Simple packages the internal setup method is used, but the parallel install requires using the external setup method. Since you don't have Cabal-1.20.0.1 installed, the setup script is compiled against Cabal-1.18.

One solution is to install the matching version of the Cabal library, or to ship an older version of cabal-install. Haskell Platform does the latter.

[ndmitchell]

@23Skidoo, that's pretty bad. If @snoyberg and I ship an old version then as soon as someone does cabal update they get a warning message saying they should upgrade. If we ship a newer version then cabal install and cabal configure use different versions. I'd consider that a pretty bad bug in parallel install - why can't parallel install just use the cabal.exe it comes with for internal builds? For example, add an extra (hidden) mode to cabal.exe that does whatever the external setup method does?

[snoyberg]

I still regularly run into bugs and confusion around this. I don't remember what the last issue was I commented on regarding this problem, but I'd love if this situation was improved.

[23Skidoo]

as soon as someone does cabal update they get a warning message saying they should upgrade.

This was removed recently.

For example, add an extra (hidden) mode to cabal.exe that does whatever the external setup method does?

That's how I implemented it initially, but @dcoutts thought that the patch was too intrusive. Why can't you ship a new version of Cabal if you are already shipping a new cabal-install? Having two Cabals installed should work fine.

IIRC @ttuegel was looking into making reconfigure happen automatically when the Cabal version has changed (#2214).

[dcoutts]

Mmm, the fact that it switches back and forth due to using parallel or not is pretty bad in terms of knock-on consequences. Though having picked an older one ideally we shouldn't then insist on switching back again.

[ndmitchell]

Installing the newer Cabal and switching back seems undesirable - the old Cabal doesn't work for many of the things I want to do (including generate documentation, as my Haddock is somewhere with a space in it). Wouldn't just having a submode to cabal so that cabal install in parallel uses the compiled version work better? I think the original design by @23Skidoo sounds preferable.

We are aiming to ship a vanilla GHC release with some extra binaries that should have been in the GHC binary all along (e.g. cabal). Upgrading the packages inside GHC isn't feasible, because we are just repackaging.

[ttuegel]

This is a duplicate of #1938.

[dcoutts]

I think I must have misunderstood @23Skidoo's approach. I agree it's sensible. @tibbe and I implemented it yesterday, see #2633.

[tibbe]

#2633 fixes this:

$ pwd
/tmp/ghcid-0.3.6
$ ghc-pkg list Cabal
/usr/local/lib/ghc-7.10.1/package.conf.d
   Cabal-1.22.2.0
/Users/tibbe/.ghc/x86_64-darwin-7.10.1/package.conf.d
$ ~/src/cabal/cabal-install/dist/build/cabal/cabal --version
cabal-install version 1.23.0.0
using version 1.23.0.0 of the Cabal library
$ ~/src/cabal/cabal-install/dist/build/cabal/cabal install --verbose
...
Ready to install ghcid-0.3.6
Configuring ghcid-0.3.6...
/Users/tibbe/src/cabal/cabal-install/dist/build/cabal/cabal act-as-setup
--build-type=Simple -- configure --verbose=2 --ghc
...
$ ~/src/cabal/cabal-install/dist/build/cabal/cabal haddock
Running Haddock for ghcid-0.3.6...
Preprocessing library ghcid-0.3.6...
...
Documentation created: dist/doc/html/ghcid/index.html
Preprocessing executable 'ghcid' for ghcid-0.3.6...

So as you can see no setup executable is built and cabal just calls itself.