"cabal install --lib" is not idempotent

[jwaldmann]

I am doing "cabal install" (in a source dir of a project that has a cabal file) This works:

cabal v2-install  --lib --package-env=tidal

It creates a file $HOME/.ghc/x86_64-linux-8.6.5/environments/tidal.

When I run the exact same command a second time, I get

cabal: Could not resolve dependencies:
[__0] trying: base-4.12.0.0/installed-4.1... (user goal)
[__1] next goal: binary (user goal)
[__1] rejecting: binary-0.8.7.0 (constraint from user target requires
==0.8.6.0)
[__1] trying: binary-0.8.6.0/installed-0.8...
[__2] next goal: containers (user goal)
[__2] rejecting: containers-0.6.2.1 (conflict: binary =>
containers==0.6.0.1/installed-0.6...)
[__2] rejecting: containers-0.6.1.1, containers-0.6.0.1/installed-0.6...,
containers-0.6.0.1, containers-0.5.11.0, containers-0.5.10.2,
...
[__2] fail (backjumping, conflict set: binary, containers)

I expect that the second command suceeds (and changes nothing).

There is a similar ticket #6391 [EDIT: repaired the reference] but it's different: the re-install seems to succeed but the resulting env file cannot be used.

System information

• Fedora GNU/Linux x86_64
• cabal-install 3.0.0.0, ghc-8.6.5 (same with 8.8.1, 8.10.1-alpha - for these I add --allow-newer)

[yaxu]

A duplicate of #6391

[m-renaud]

Hi @jwaldmann, I wasn't able to reproduce this locally with a minimal cabal library. Do you have a specific repro case I could check out?

$ cabal --version
cabal-install version 3.0.0.0
compiled using version 3.0.0.0 of the Cabal library

[jwaldmann]

I am seeing this (using the tidal package from hackage)

$ rm ~/.ghc/x86_64-linux-8.8.3/environments/tidal 
$ cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library 
$ cabal  --package-env=tidal install tidal-1.4.9 --lib
Resolving dependencies...
Up to date
$ cabal  --package-env=tidal install tidal-1.4.9 --lib
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: directory-1.3.6.1 (user goal)
[__1] next goal: ghc (user goal)
[__1] rejecting: ghc-8.8.3/installed-8.8.3 (conflict: directory==1.3.6.1, ghc
=> directory==1.3.6.0/installed-1.3.6.0)
[__1] rejecting: ghc-8.6.5, ghc-8.6.4, ghc-8.6.1, ghc-8.4.4, ghc-8.4.3,
ghc-8.4.1, ghc-8.2.2, ghc-8.2.1 (constraint from user target requires ==8.8.3)
[__1] fail (backjumping, conflict set: directory, ghc)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: directory, ghc

[m-renaud]

Ahh, I see. Yes trying to install --lib the same package from hackage multiple times is a separate issue than reinstalling the same local package after modifications. In your initial report you had cabal install --lib with no package specified, which afaik doesn't lead to this issue, correct?

[jwaldmann]

looks the same:

$ cabal unpack tidal-1.4.9
Unpacking to tidal-1.4.9/
$ cd tidal-1.4.9/
$ cabal  --package-env=fresh install  --lib
Wrote tarball sdist to
/home/waldmann/tmp/tidal-1.4.9/dist-newstyle/sdist/tidal-1.4.9.tar.gz
Resolving dependencies...
Up to date
$ cabal  --package-env=fresh install  --lib
Wrote tarball sdist to
/home/waldmann/tmp/tidal-1.4.9/dist-newstyle/sdist/tidal-1.4.9.tar.gz
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: directory-1.3.6.1 (user goal)
[__1] next goal: ghc (user goal)
[__1] rejecting: ghc-8.8.3/installed-8.8.3 (conflict: directory==1.3.6.1, ghc
=> directory==1.3.6.0/installed-1.3.6.0)
[__1] rejecting: ghc-8.6.5, ghc-8.6.4, ghc-8.6.1, ghc-8.4.4, ghc-8.4.3,
ghc-8.4.1, ghc-8.2.2, ghc-8.2.1 (constraint from user target requires ==8.8.3)
[__1] fail (backjumping, conflict set: directory, ghc)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: directory, ghc

[TristanCacqueray]

I'm having a similar issue where cabal install --lib somehow always fails, for example with this simple project:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5
$ cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library 

$ git clone https://github.com/softwarefactory-project/gerrit-haskell
$ pushd gerrit-haskell
$ rm -Rf ~/.ghc/
$ cabal install --lib
Wrote tarball sdist to
/home/fedora/gerrit-haskell/dist-newstyle/sdist/gerrit-0.0.0.0.tar.gz
Resolving dependencies...
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - gerrit-0.0.0.0 (lib) (requires build)
Starting     gerrit-0.0.0.0 (lib)
Building     gerrit-0.0.0.0 (lib)
Installing   gerrit-0.0.0.0 (lib)
Completed    gerrit-0.0.0.0 (lib)
$ ghci
Prelude> import Gerrit
Prelude Gerrit> :quit

$  cabal install --lib
Wrote tarball sdist to
/home/fedora/gerrit-haskell/dist-newstyle/sdist/gerrit-0.0.0.0.tar.gz
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] next goal: base (user goal)
[__0] rejecting: base-4.14.0.0, base-4.13.0.0 (constraint from user target
requires ==4.12.0.0)
[__0] trying: base-4.12.0.0/installed-4.12.0.0
[__1] trying: directory-1.3.6.1 (user goal)
[__2] next goal: ghc (user goal)
[__2] rejecting: ghc-8.10.1, ghc-8.8.3, ghc-8.8.1 (constraint from user target
requires ==8.6.5)
[__2] rejecting: ghc-8.6.5/installed-8.6.5 (conflict: directory==1.3.6.1, ghc
=> directory==1.3.3.0/installed-1.3.3.0)
[__2] trying: ghc-8.6.5
[__3] rejecting: ghc:-buildable (conflict: base==4.12.0.0/installed-4.12.0.0,
ghc -buildable => base<0)
[__3] rejecting: ghc:+buildable (manual flag can only be changed explicitly)
[__3] fail (backjumping, conflict set: base, ghc, ghc:buildable)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: directory, base, ghc, ghc:buildable
Try running with --minimize-conflict-set to improve the error message.

At this point, any cabal install --lib command result in the same error.

The use-case is to be able to use the library globally, for example in a Shakefile. It seems like the current workaround is to remove the ~/.ghc folder before doing the lib install.

[yaxu]

For now I think the best answer is to use v1-install instead. Would it be reasonable to switch that back to being the default?

[gbaz]

I think the workaround is to just use a new environment file specification each time?

[yaxu]

You don't need a workaround with v1-install

[georgefst]

I think the workaround is to just use a new environment file specification each time?

That's what I do in practice but it's fairly annoying. In my use cases, it would mostly be fine if cabal scripts generated environment files properly. But unfortunately there's #6999.