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
--allow-newer)A duplicate of #6391
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
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
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?
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
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.
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?
I think the workaround is to just use a new environment file specification each time?
You don't need a workaround with v1-install
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.
There's also the cabal-env prototype by phadej. Please leave feedback in #6481 if you try it!
Thanks @fgaz, I'll have a look!
There's also the cabal-env prototype by phadej. Please leave feedback in #6481 if you try it!
Thanks for the suggestion - it already seems to be a lot more usable than install --lib.
With cabal-install version 3.2.0.0, tidal-1.6.1 (current on hackage), things seem to work with ghc-8.10.2 and ghc-8.8.4. With ghc-8.6.5, the problem happens as reported.
Interesting: it seems if I explicitly install process, for example, the environment will contain prcss-$VERSION-$HASH and a reinstall results in a failed constraint solver error message, but if it's installed as a dependency of another package, it shows in the environment file as process-$VERSION and an explicit reinstall just says it's up to date.
I don't get this issue with aeson. I do with pretty-simple.
Most helpful comment
looks the same: