I am trying to install the yesod web framework.
When I run cabal install yesod-platform, I get a dependency conflict:
cabal: dependencies conflict: ghc-7.0.4 requires array ==0.3.0.2 however
array-0.3.0.2 was excluded because http-conduit-1.8.7 requires array >=0.4
I get this error even in a hsenv sandboxed environment.
What can I do?
As Daniel Fischer says, this is not a dependency conflict so much as a recognition that yesod doesn't support 7.0.4, and hence your dependencies are outdated. 7.0.4 is well before the current Haskell Platform, and you should upgrade.
Related
I'm trying to install aeson on GHC 9.2.1. I first ran cabal install --allow-newer --lib aeson, which failed when it got to building attoparsec. It turns out this problem is already fixed in their Git repo, but hasn't landed in a release on Hackage yet. I then did these steps to build a local version with the fix:
git clone https://github.com/haskell/attoparsec.git
cd attoparsec
cabal install --allow-newer --lib .
cd ..
That succeeded, but then when I did cabal install --allow-newer --lib aeson again, it tried to build attoparsec from Hackage again, and so failed again. How can I make cabal use what I just built and installed instead?
There are two main methods.
One is to create a cabal project that includes both the cloned version of attoparsec and the local packages that you are working on (packages that might depend on aeson). It could be as simple as
packages: attoparsec yourpackage
In fact, you don't even need to clone the repo, you could use the source-repository-package field instead.
Because local packages always take precedence over external ones, the repo version will be chosen when resolving dependencies.
This approach works well but has the disadvantage that if you use the patched attoparsec in many different projects, you'll have to reference and re-compile it each time.
Another approach is to create a local no-index package repository in your machine, give it priority over stardard Hackage, and put attoparsec's sdist tarball there.
You need to declare the extra package repository using the repository field of your global cabal config (the path to the config is displayed in the last line of cabal help). By default, there's only Hackage:
repository hackage.haskell.org
url: http://hackage.haskell.org/
To give the local package repository priority over Hackage, you need to use the active-repositories field, either in your global Cabal config or in a cabal.project file.
The advantage of this method is that you don't need to create a Cabal project, and that the patched version of attoparsec will only be compiled once (as if it came from Hackage).
I just upgraded to the latest version of cabal-install which is 1.20. I am not sure if it is related but cabal started fetching old versions of packages for some reason.
In my cabal file, all dependencies are specified without version numbers. So I believe, cabal should fetch the latest versions available unless there is a conflict, correct?
If I run cabal install --only-dependencies within a sandbox environment, cabal pulls all kind of rubbish and old package versions like mongoDB-1.2.2 instead of 1.4.4 and scotty-0.5 instead of 0.7.2. If I run a specific package installation like cabal install scotty then it fetches the latest version and all is well. So I have to install all dependencies manually to get the latest versions - one by one. Annoying. What is going on?
Google gives me no hits.
If there are some kind of changes in cabal, what is it? And how do I pull all the latest dependencies within a sandbox.
Thanks.
Some of your dependencies have upper bounds that are forcing the usage of older versions of a given package. One thing that might help is to start over. Delete your package repository (~/.ghc on linux machines), and keep a discipline to work entirely within sandboxes. Use your package manager to install stuff you need globally, sandboxes for your development projects, and you can avoid a lot of the reasons this problem crops up. That said, if you're truly depending on a project that hasn't updated its upper bounds, then you're stuck using the older packages, short of submitting a patch to the library author or switching to a different dependency.
Lets MyLib be my local Haskell library. I can build it with cabal build and install it with cabal install, but can I use it in other projects without the installation step?
I'm developing several libraries and installing them after every change is not a good solution.
Let's say you have two entirely separate projects, one called my-library and another called my-project. And my-project depends on my-library.
The way to build my-library and make it available to other projects is cabal install my-library. Once that's done, any other project can use the library.
Now you're ready to build my-project using the command cabal install my-project. It will not rebuild or reinstall my-library, but it will link your project with the library.
Now, if you make modifications to my-library, be sure to update the version number before running cabal install my-library. If you forget to bump the version number, you will be warned that my-project will be made obsolete. Now the old version and the new version of your library are available to other projects.
You can continue to run your projects. They will happily continue to use the previous version of my-library until you do another cabal install my-project. So there is no need to re-install everything after every change.
If you do want to rebuild your projects, but continue to work with an older version of your library, you can specify that in the build-depends section of your cabal file. For example, if you have versions 1.0 and 2.0 of my-library installed, you can build your project against the older version like this:
build-depends: my-library==1.0, ...
There isn't a great solution to your problem, but you can use sandboxes to keep your development environment a bit cleaner.
With cabal-1.18 or newer, you can create a sandbox with cabal sandbox init and then you can either install to that sandbox or add-source (cabal sandbox add-source <path to library>).
This helps to keep unstable libraries (and their potentially unstable dependencies) out of your user package database, and that can help prevent 'cabal hell' (unsolvable conflicts between dependencies). However, that doesn't directly help reduce the number of commands you need to issue each time you want to do a top-level build.
What you can do though, is set up a simple script that performs the add-source commands and builds your top-level package. eg:
#!/bin/bash
cabal sandbox init # a no-op if the sandbox exists.
cabal sandbox add-source ../MyLib
cabal install --dependencies-only
cabal build
Granted, you could do that before, but this time you can also easily clean up (removing all the installed artifacts) by cleaning the sandbox:
cabal sandbox delete
Here's the complete error:
$ cabal install hakyll
Resolving dependencies...
cabal: cannot configure snap-server-0.5.3.1. It requires base >=4.3 && <5
For the dependency on base >=4.3 && <5 there are these packages: base-4.3.0.0,
base-4.3.1.0 and base-4.4.0.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
base-4.4.0.0 was excluded because of the top level dependency base -any
$
How can versions of base-* be excluded due to some rule that appears to say that any version is fine?
Every time I have run into this problem, it has been because I did all of the following things:
Downloaded a package from Hackage with outdated dependencies.
Updated the dependencies and observed that it built fine (or spent time fixing whatever errors occurred).
Ran cabal install with the new dependencies.
Didn't update the version number.
That last one is the real kicker. cabal install will assume that, if it knows of a package's version/dependencies pair from Hackage, that pair is canonical. If you want it to know about updated dependencies, change the package's version number before you install.
You will need to check that you've done this correctly for any of hakyll's dependencies that you have manually installed.
Ran into the same problem. Solved it.
It was a clean haskell install. But it was a clean haskell install from the linux flavor's (in this case ubuntu) package manager which had older versions.
Had to remove the old packages & download the source & build & install it.
get the latest platform sources from:
http://hackage.haskell.org/platform/linux.html
get the ghc sources that are required for the platform.
http://haskell.org/ghc/download_ghc_7_0_3#distros
an example for doing this:
http://sporkcode.wordpress.com/2009/07/11/installing-the-haskell-platform-in-ubuntu/
So I'm trying to install a package with a big messy dependency set (gitit, in this case). A direct cabal install from hackage forces rebuilds of plenty of libraries I don't want to rebuild (having to do with constraints on text, constraints on network, constraints on parsec, etc.) I did the right thing, ran cabal unpack gitit, manually edited the .cabal file, and successfully put it through a cabal configure, cabal build cycle. So far, so good.
Now, I want to run a cabal install. In the good old days (last year), this would just install the already built binaries and files where they belong. However, now, running cabal install runs the dependency checker, which decides that all the packages that I'm building with don't use the same parsec, etc., and tries to reinstall them anyway! Even though I just ran a perfectly fine cabal build. What's the magic flag to turn this off and get the old, not-clever, and perfectly acceptable behavior?
Looking at the flags, there doesn't seem to be any indication of cabal install doing this. In times of yore, before cabal install and when you had to manually get your own packages, the incantation at the install stage was runghc Setup install --user after you had run runghc Setup configure --prefix=$FOO --user - perhaps this will work? Setup.hs will not automatically invoke 'build' when you tell it to 'install', if my memory serves correctly.
Now, for the future, if you want to avoid this entire nasty dependency hell, I would highly suggest you use cabal-dev which will sandbox your package installations and never touch your actual user/global package database, in this case you'd just do:
$ cabal unpack gitit
$ cd gitit-0.8.0.1 # latest hackage version
$ cabal-dev install
It'll properly download and install all the needed dependencies like cabal install, but it'll sandbox them by creating a ./cabal-dev directory containing a self-contained package database. It never touches your global or user package db in ~/.ghc/. cabal-dev effectively makes editing cabal files and dealing with the diamond dependency problems Cabal faces a thing of the past, the way cabal-install made manually downloading packages a thing of the past.
It also turns out that there is an --only flag that lets one build and install only that package, just as the ./Setup route does.