Cabal has dependency problems constantly. It's really tiring. So far I have tried to get many things working, here's my trying to install snap:
$ sudo cabal install snap-server
Resolving dependencies...
cabal: cannot configure ListLike-1.1.0. It requires mtl >=1.1.0 && 1.2
For the dependency on mtl >=1.1.0 && 1.2 there are these packages:
mtl-1.1.0.0, mtl-1.1.0.1, mtl-1.1.0.2 and mtl-1.1.1.0. However none of them
are available.
mtl-1.1.0.0 was excluded because mtl-2.0.0.0 was selected instead
mtl-1.1.0.0 was excluded because monads-fd-0.1.0.3 requires mtl ==2.*
mtl-1.1.0.1 was excluded because mtl-2.0.0.0 was selected instead
mtl-1.1.0.1 was excluded because monads-fd-0.1.0.3 requires mtl ==2.*
mtl-1.1.0.2 was excluded because mtl-2.0.0.0 was selected instead
mtl-1.1.0.2 was excluded because monads-fd-0.1.0.3 requires mtl ==2.*
mtl-1.1.1.0 was excluded because mtl-2.0.0.0 was selected instead
mtl-1.1.1.0 was excluded because monads-fd-0.1.0.3 requires mtl ==2.*
I have similar problems installing Happstack, etc. What is the procedure to make cabal...work?
I've already tried:
export PATH=/home/user/.cabal/bin:$PATH
The problem is that snap-server-0.2.15 has an unbounded dependency on monads-fd. The most recent version, monads-fd-0.1.0.3, requires mtl-2.* Unfortunately this conflicts with the dependency on ListLike (via iteratee), which requires mtl < 2.0. Both of these constraints can't be fulfilled simultaneously, so cabal gives up.
Try running cabal install snap-server --constrain="monads-fd=0.1.0.2". That will force an earlier version of monads-fd that doesn't require mtl, and I think everything will work properly.
If you're having problems with a lot of packages, it's probably due to the new mtl that was recently uploaded. You can try adding --constrain="mtl<2", which might help.
Moral to maintainers: follow the Haskell PVP and always use upper dependency bounds.
N.B. Even if I do upload a new ListLike that works with mtl-2 (which I'll do very soon), that won't fix your problem because the new ListLike won't be selected due to the upper bound on iteratee.
Related
I'm trying to build my package using a sandbox. Without it, it compiles and works like a charm. Once I introduce a sandbox though cabal says it can't resolve dependencies. To my eyes these conflicts do not look like conflicts though.
The project structure is as follows:
application (depends on library-base, library-impl1 and library-impl2)
library
├ library-base
├ library-impl1 (depends on library-base)
└ library-impl2 (depends on library-base)
These are the commands I ran in that order
rm -rf ~/.cabal
rm -rf ~/.ghc
cabal update
rm -f cabal.sandbox.config
rm -rf .cabal-sandbox
cabal sandbox init
cabal sandbox add-source $LIB_HOME/library-base
cabal sandbox add-source $LIB_HOME/library-impl1
cabal sandbox add-source $LIB_HOME/library-impl2
cabal install --only-dependencies --force-reinstalls && cabal build
cabal install --only-dependencies --force-reinstalls produces the following output:
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: lens (dependency of library-base-0.1.0.0)
rejecting: lens-4.15.4/installed-I5C... (conflict: bifunctors==5.4.2, lens =>
bifunctors==5.4.2/installed-Hs7...)
trying: lens-4.15.4
trying: unordered-containers-0.2.8.0/installed-1tq... (dependency of
lens-4.15.4)
next goal: text (dependency of lens-4.15.4)
rejecting: text-1.2.2.2/installed-3EN... (conflict: binary==0.8.5.1, text =>
binary==0.8.3.0/installed-0.8...)
trying: text-1.2.2.2
next goal: hashable (dependency of lens-4.15.4)
rejecting: hashable-1.2.6.1/installed-2nP... (conflict: text==1.2.2.2,
hashable => text==1.2.2.2/installed-3EN...)
rejecting: hashable-1.2.6.1, hashable-1.2.6.0, hashable-1.2.5.0,
hashable-1.2.4.0, hashable-1.2.3.3, hashable-1.2.3.2, hashable-1.2.3.1,
hashable-1.2.3.0, hashable-1.2.2.0, hashable-1.2.1.0, hashable-1.2.0.10,
hashable-1.2.0.9, hashable-1.2.0.8, hashable-1.2.0.7, hashable-1.2.0.6,
hashable-1.2.0.5, hashable-1.2.0.4, hashable-1.2.0.3, hashable-1.2.0.2,
hashable-1.2.0.1, hashable-1.2.0.0, hashable-1.1.2.5, hashable-1.1.2.4,
hashable-1.1.2.3, hashable-1.1.2.2, hashable-1.1.2.1, hashable-1.1.2.0,
hashable-1.1.1.0, hashable-1.1.0.0, hashable-1.0.1.1, hashable-1.0.1.0,
hashable-1.0.0 (conflict: unordered-containers =>
hashable==1.2.6.1/installed-2nP...)
Dependency tree exhaustively searched.
Does anyone have an idea what is going on here?
First I will give an explanation of what the error message says. Then I will attempt to make some guesses about why you have the error. Then I will propose some next steps.
The error says:
Maybe version 4.15.4 of lens will work.
Maybe the installed version 0.2.8.0 of unordered-containers will satisfy lens' dependency on unordered-containers.
Maybe the installed version 1.2.2.2 of text will satisfy lens' dependency on text.
Crap. You asked for version 0.8.5.1 of binary, but the installed version of text was built against version 0.8.3.0. I have to rebuild text.
Maybe the installed version 1.2.6.1 version of hashable will satisfy lens' dependency on hashable.
Crap. We're rebuilding text, a dependency of hashable. I have to rebuild hashable.
Double crap. We already committed to using the installed version of unordered-containers, which depends on the installed version of hashable, which prevents us from rebuilding hashable.
(...and I tried a bunch of other stuff that didn't work, too, but I'm not telling you what, nya nya nya)
Normally sandboxes ignore local package databases, so this suggests to me that where it is talking about "installed versions" above it is either picking these up from your global package database or from your existing sandbox. You claim that you have just created this sandbox and run this cabal install command immediately. If this is true (is it? or is this a second run of the tool? why do you have --force-reinstalls?), it cannot be picking the installed versions from your sandbox, and therefore must be picking them up from your global package database. Installing things to the global package database is generally considered a Bad Idea, because it's much more difficult to correctly clear out a cluttered/broken global package database. Take it under future advisement.
Now, to make progress, I would try one of these two things:
The only part of the above error explanation that you have control over is the "You asked for version 0.8.5.1 of binary" part. Consider relaxing your version constraints on binary to accept the already-installed version 0.8.3.0.
You can often get significantly better error messages out of cabal by cutting down on its search space; because it only prints a part of the search space in its error, you sometimes need to guide it to the problematic part of the space so that it will show you the real problem in its error. If you're pretty sure the installed versions of unordered-containers et al are a good match for your library, consider
cabal install --only-dependencies --constraint 'unordered-containers installed' --constraint 'binary installed'
and so on for any other packages it mentions trying to rebuild that you don't want it to rebuild. Alternately you can put exact version constraints in the --constraint if you don't want one of the installed versions. Don't include --force-reinstalls, basically ever.
Different programming languages use different packaging systems.
In their varied approach, Java's Maven looks like the best bet for me since it maintains different version of jar files in seperately versioned folders and hence, there is no way one will end up in conflicting versions of a library.
Next comes python. Python's pip puts its packages into /usr/local/lib/python/dist-packages/site-packages. When there is a version conflict, one can use its virtualenv and live with it.
Nodejs supports installing packages both in local folders and global folders. Till date for me, i never had a dependency conflict in the global libraries.
Then I got fascinated by the haskell's style and started using cabal. First, i was installing my libraries inside /home/user1/.cabal. Then when the package system broke, one friend suggested me to remove two folders - /home/user1/.cabal && /home/user1/.ghc. Now, my first confusion arose, why does cabal's library files sit in two folders .cabal && .ghc. I cleaned the library folders, ~/.ghc and ~/.cabal and did cabal install from a package source for cabal-db-0.1.12. Now, there was a new error and i was surprised, because i had sanitized all local repositories. The error was,
Configuring Cabal-1.22.2.0...
Building Cabal-1.22.2.0...
Installed Cabal-1.22.2.0
cabal: Error: some packages failed to install:
ansi-terminal-0.6.2.1 failed during the configure step. The exception was:
user error (The package 'ansi-terminal' requires Cabal library version -any &&
>=1.6 but no suitable version is installed.)
Then I tried the safest bet - sandbox for cabal-db. It worked. Then i repeated sandboxing for another pacakge, ghc-pkg-autofix. I did,
cd ghc-pkg-autofix-0.2.0.1
cabal sandbox init
cabal install
And for sandbox where there are absolutely no external dependencies, there are errors again,
cabal: Could not resolve dependencies:
trying: ghc-pkg-autofix-0.2.0.1 (user goal)
trying: Cabal-1.22.2.0 (dependency of ghc-pkg-autofix-0.2.0.1)
next goal: process (dependency of ghc-pkg-autofix-0.2.0.1)
rejecting: process-1.2.0.0/installed-06c..., 1.2.3.0, 1.2.2.0, 1.2.1.0,
1.2.0.0, 1.1.0.2, 1.1.0.1, 1.1.0.0 (conflict: ghc-pkg-autofix => process>=1.0
&& <1.1)
rejecting: process-1.0.1.5, 1.0.1.4, 1.0.1.3, 1.0.1.2, 1.0.1.1, 1.0.0.0
(conflict: Cabal => process>=1.1.0.1 && <1.3)
Dependency tree exhaustively searched.
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
Am i doing something wrong (or) this kind of dependency conflicts are quite common in cabal? I see, managing dependencies in other languages are a lot simpler.
Note: I use cabal-install version 1.22.0.0 && The Glorious Glasgow Haskell Compilation System, version 7.8.4
"And for sandbox where there are absolutely no external dependencies" this is not true. A sandbox still has dependencies on the global package database. Things like Cabal, GHC, process are typically installed in the global package database. Here you want to install ghc-pkg-autofix which requires process 1.0, but you have a more recent version of process already installed. Are you sure you need ghc-pkg-autofix, it seems to be quite old.
I want to use Yesod web framework with yesod-auth-oauth, but I encountered a dependency problem while cabal-dev install:
/Users/kenta/myapp/oryza% cabal-dev install
Resolving dependencies...
cabal: cannot configure yesod-platform-1.0.2. It requires data-default ==0.4.0
For the dependency on data-default ==0.4.0 there are these packages:
data-default-0.4.0. However none of them are available.
data-default-0.4.0 was excluded because authenticate-oauth-1.3.0 requires
data-default ==0.3.*
data-default-0.4.0 was excluded because data-default-0.3.0 was selected
instead
data-default-0.4.0 was excluded because oryza-0.0.0 requires data-default
==0.3.*
I don't have any idea of what's wrong.
What I did is just inserting one line in Cabal file:
yesod-auth-oauth >= 1.0 && < 1.1
The default scaffolding works fine, which is created through yesod init.
The version information
yesod-core: 1.0.1
cabal-dev: 0.9.1 (build with Cabal 1.14.0)
cabal-install: 0.10.2
GHC: 7.0.4
OS: Mac OS X Lion
Thanks.
This looks like an overly restrictive upper bound in the authenticate-oauth package. It would be best to follow up directly with the maintainer of that package.
In general, these kinds of issues are a side-effect of following the Package Versioning Policy. Basically, it's a trade-off between having these "refuse to compile" annoyances and more insidious "can't compile" problems.
I don't remember for sure, but I think my change to the cabal file for yesod-auth-oauth fixes this.
Has anybody managed to get Yorgey et al's "unbound" library, for working with syntax with binding, to install with the latest GHC (7.0.3) and Haskell platform? Trying a cabal install unbound, I get the following:
Resolving dependencies...
cabal: cannot configure unbound-0.2.3. It requires base >=4.3 && <5
For the dependency on base >=4.3 && <5 there are these packages: base-4.3.0.0
and base-4.3.1.0. However none of them are available.
base-4.3.0.0 was excluded because of the top level dependency base -any
base-4.3.1.0 was excluded because of the top level dependency base -any
Anybody know a solution/work around, or what may be happening here?
Just to close this one:
The "unbound" library works fine with the 2011 Haskell Platform, and indeed, builds without warnings.
The OP had multiple (older) versions of GHC in his path, leading to build errors, since the package relies on GHC 7. Ensuring you have exactly the Haskell Platform environment is the solution.
As a note, we should write a script that checks the sanity of a given Haskell environment, to catch errors like this.
I tried installing Djinn by using cabal but got the following error -
$ cabal install djinn --verbose
Reading available packages...
Resolving dependencies...
cabal: cannot configure djinn-2009.9.3. It requires base ==3.*
For the dependency on base ==3.* there are these packages: base-3.0.3.1 and
base-3.0.3.2. However none of them are available.
base-3.0.3.1 was excluded because of the top level dependency base -any
base-3.0.3.2 was excluded because of the top level dependency base -any
The error message is mysterious, shouldn't base -any allow base version 3.0.3.1?
From the Haskell Mailing list:
It's not a great error message. Now, base is a special package. It comes with ghc, and cannot be upgraded. That's why Cabal will rule out all base versions but the one you already have installed. If you have a recent ghc, that'll be base-4.
Hope that helps.
AFAIK, GHC 7 does not ships base in version 3 anymore. The best idea would robably be to notify the maintainer (lennart*at*augustsson.net) to update the package. An ad-hoc fix would be to download the package from here, unpack it and manually edit the file djinn.cabal so that the dependency on base is base 4.*. It may or may not work, but most times it's worth a try.