Why does omitting cabal-version cause the build to fail? - haskell

I have a minimal example project:
Test
Test
Test.hs
Test.cabal
Test.hs contains an empty module Test.Test. The contents of Test.cabal are as follows:
name: Test
version: 0.0.0
library
build-depends: base
exposed-modules: Test.Test
Running cabal build fails with a long, confusing error message (copied below) unless I add cabal-version: 2.2 to the cabal file. Higher than 2.2 works as well but lower versions result in a similar error. My cabal version is 3.2. Why does the build fail unless I specify a cabal version and why are versions lower than 2.2 not sufficient?
The error message that I get without specifying cabal version is as follows:
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: Test-0.0.0 (user goal)
[__1] next goal: Test:setup.Cabal (dependency of Test)
[__1] rejecting: Test:setup.Cabal-3.2.0.0/installed-3.2.0.0 (conflict: Test =>
Test:setup.Cabal>=0 && <1.25)
[__1] skipping: Test:setup.Cabal-3.6.3.0, Test:setup.Cabal-3.6.2.0,
Test:setup.Cabal-3.6.1.0, Test:setup.Cabal-3.6.0.0, Test:setup.Cabal-3.4.1.0,
Test:setup.Cabal-3.4.0.0, Test:setup.Cabal-3.2.1.0, Test:setup.Cabal-3.2.0.0,
Test:setup.Cabal-3.0.2.0, Test:setup.Cabal-3.0.1.0, Test:setup.Cabal-3.0.0.0,
Test:setup.Cabal-2.4.1.0, Test:setup.Cabal-2.4.0.1, Test:setup.Cabal-2.4.0.0,
Test:setup.Cabal-2.2.0.1, Test:setup.Cabal-2.2.0.0, Test:setup.Cabal-2.0.1.1,
Test:setup.Cabal-2.0.1.0, Test:setup.Cabal-2.0.0.2 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=0 && <1.25' from 'Test')
[__1] rejecting: Test:setup.Cabal-1.24.2.0, Test:setup.Cabal-1.24.0.0,
Test:setup.Cabal-1.22.8.0, Test:setup.Cabal-1.22.7.0,
Test:setup.Cabal-1.22.6.0, Test:setup.Cabal-1.22.5.0,
Test:setup.Cabal-1.22.4.0, Test:setup.Cabal-1.22.3.0,
Test:setup.Cabal-1.22.2.0, Test:setup.Cabal-1.22.1.1,
Test:setup.Cabal-1.22.1.0, Test:setup.Cabal-1.22.0.0,
Test:setup.Cabal-1.20.0.4, Test:setup.Cabal-1.20.0.3,
Test:setup.Cabal-1.20.0.2, Test:setup.Cabal-1.20.0.1,
Test:setup.Cabal-1.20.0.0, Test:setup.Cabal-1.18.1.7,
Test:setup.Cabal-1.18.1.6, Test:setup.Cabal-1.18.1.5,
Test:setup.Cabal-1.18.1.4, Test:setup.Cabal-1.18.1.3,
Test:setup.Cabal-1.18.1.2, Test:setup.Cabal-1.18.1.1, Test:setup.Cabal-1.18.1,
Test:setup.Cabal-1.18.0, Test:setup.Cabal-1.16.0.3, Test:setup.Cabal-1.16.0.2,
Test:setup.Cabal-1.16.0.1, Test:setup.Cabal-1.16.0, Test:setup.Cabal-1.14.0,
Test:setup.Cabal-1.12.0, Test:setup.Cabal-1.10.2.0, Test:setup.Cabal-1.10.1.0,
Test:setup.Cabal-1.10.0.0, Test:setup.Cabal-1.8.0.6, Test:setup.Cabal-1.8.0.4,
Test:setup.Cabal-1.8.0.2, Test:setup.Cabal-1.6.0.3, Test:setup.Cabal-1.6.0.2,
Test:setup.Cabal-1.6.0.1, Test:setup.Cabal-1.4.0.2, Test:setup.Cabal-1.4.0.1,
Test:setup.Cabal-1.4.0.0, Test:setup.Cabal-1.2.4.0, Test:setup.Cabal-1.2.3.0,
Test:setup.Cabal-1.2.2.0, Test:setup.Cabal-1.2.1, Test:setup.Cabal-1.1.6,
Test:setup.Cabal-1.24.1.0 (constraint from minimum version of Cabal used by
Setup.hs requires >=3.2)
[__1] fail (backjumping, conflict set: Test, Test:setup.Cabal)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: Test:setup.Cabal, Test

Related

How to handle following dependency conflict in Cabal?

When I try to add scotty package to my multi-project cabal file, I get following dependency conflict. I am not exactly sure what it means.
harshal#Harshals-Linux hello-haskell % cabal build
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: playground-0.1.0.0 (user goal)
[__1] trying: scotty-0.12.1 (dependency of playground)
[__2] trying: warp-3.3.23 (dependency of scotty)
[__3] trying: unix-compat-0.6 (dependency of warp)
[__4] trying: unix-2.7.3/installed-2.7.3 (dependency of warp)
[__5] next goal: directory (dependency of playground)
[__5] rejecting: directory-1.3.7.1/installed-1.3.7.1 (conflict: playground =>
directory>=1.3.8.0)
[__5] rejecting: directory-1.3.8.0 (conflict: unix==2.7.3/installed-2.7.3,
directory => unix>=2.8.0 && <2.9)
[__5] rejecting: directory-1.3.7.1 (conflict: playground =>
directory>=1.3.8.0)
[__5] skipping: directory-1.3.7.0, directory-1.3.6.2, directory-1.3.6.1,
directory-1.3.6.0, directory-1.3.5.0, directory-1.3.4.0, directory-1.3.3.2,
directory-1.3.3.1, directory-1.3.3.0, directory-1.3.2.2, directory-1.3.2.1,
directory-1.3.2.0, directory-1.3.1.5, directory-1.3.1.4, directory-1.3.1.3,
directory-1.3.1.2, directory-1.3.1.1, directory-1.3.1.0, directory-1.3.0.2,
directory-1.3.0.1, directory-1.3.0.0, directory-1.2.7.1, directory-1.2.7.0,
directory-1.2.6.3, directory-1.2.6.2, directory-1.2.5.1, directory-1.2.5.0,
directory-1.2.4.0, directory-1.2.3.1, directory-1.2.3.0, directory-1.2.2.1,
directory-1.2.2.0, directory-1.2.1.0, directory-1.2.0.1, directory-1.2.0.0,
directory-1.1.0.2, directory-1.1.0.1, directory-1.1.0.0, directory-1.0.1.2,
directory-1.0.1.1, directory-1.0.1.0, directory-1.0.0.3, directory-1.0.0.0,
directory-1.2.6.1 (has the same characteristics that caused the previous
version to fail: excluded by constraint '>=1.3.8.0' from 'playground')
[__5] fail (backjumping, conflict set: directory, playground, unix)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: directory, unix, playground,
unix-compat, warp, unix-compat:portable, scotty
Try running with --minimize-conflict-set to improve the error message.
How can I resolve this dependency conflict?
What this says:
playground-0.1.0.0 depends on directory >= 1.3.8.0
directory-1.3.8.0 is the only apparent solution to directory >= 1.3.8.0
directory-1.3.8.0 depends on unix >= 2.8.0 && <2.9
we already committed to unix==2.7.3, which does not satisfy that constraint
One thing you could try, therefore, is to give it a hint that you want to pick a newer unix, by adding a top-level constraint:
% cabal build --constraint `unix >=2.8.0 && <2.9`
Top-level constraints are "available" earlier than constraints found via searching for dependencies, and so can constrain earlier choices better. (I believe this property -- that constraints get solved and committed to in some not-totally-user-visible order -- is to make the dependency resolution algorithm more efficient. Bummer.)

Compile Haskell program with third-party dependencies

I am trying to jump into some Haskell again after being away for a while. One piece of code I wrote ages ago inclues import qualified Data.MultiMap as MultiMap. Since Data.MultipMap is in the containers package, I get errors when I just run ghc program.hs. I've attempted to write a project.cabal file based on How to make a Haskell cabal project with library+executables that still run with runhaskell/ghci?. My latest attempt is
name: project
version: 1.0
executable project
main-is: project.hs
build-dependencies:
base >= 4 && <= 5
, containers
Now when I do cabal build project, I get
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: project-1.0 (user goal)
[__1] next goal: project:setup.Cabal (dependency of project)
[__1] rejecting: project:setup.Cabal-3.4.0.0/installed-3.4.0.0 (conflict:
project => project:setup.Cabal>=1.0 && <1.25)
[__1] skipping: project:setup.Cabal-3.4.0.0, project:setup.Cabal-3.2.1.0,
project:setup.Cabal-3.2.0.0, project:setup.Cabal-3.0.2.0,
project:setup.Cabal-3.0.1.0, project:setup.Cabal-3.0.0.0,
project:setup.Cabal-2.4.1.0, project:setup.Cabal-2.4.0.1,
project:setup.Cabal-2.4.0.0, project:setup.Cabal-2.2.0.1,
project:setup.Cabal-2.2.0.0, project:setup.Cabal-2.0.1.1,
project:setup.Cabal-2.0.1.0, project:setup.Cabal-2.0.0.2 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=1.0 && <1.25' from 'project')
[__1] rejecting: project:setup.Cabal-1.24.2.0, project:setup.Cabal-1.24.0.0,
project:setup.Cabal-1.22.8.0, project:setup.Cabal-1.22.7.0,
project:setup.Cabal-1.22.6.0, project:setup.Cabal-1.22.5.0,
project:setup.Cabal-1.22.4.0, project:setup.Cabal-1.22.3.0,
project:setup.Cabal-1.22.2.0, project:setup.Cabal-1.22.1.1,
project:setup.Cabal-1.22.1.0, project:setup.Cabal-1.22.0.0,
project:setup.Cabal-1.20.0.4, project:setup.Cabal-1.20.0.3,
project:setup.Cabal-1.20.0.2, project:setup.Cabal-1.20.0.1,
project:setup.Cabal-1.20.0.0, project:setup.Cabal-1.18.1.7,
project:setup.Cabal-1.18.1.6, project:setup.Cabal-1.18.1.5,
project:setup.Cabal-1.18.1.4, project:setup.Cabal-1.18.1.3,
project:setup.Cabal-1.18.1.2, project:setup.Cabal-1.18.1.1,
project:setup.Cabal-1.18.1, project:setup.Cabal-1.18.0,
project:setup.Cabal-1.16.0.3, project:setup.Cabal-1.16.0.2,
project:setup.Cabal-1.16.0.1, project:setup.Cabal-1.16.0,
project:setup.Cabal-1.14.0, project:setup.Cabal-1.12.0,
project:setup.Cabal-1.10.2.0, project:setup.Cabal-1.10.1.0,
project:setup.Cabal-1.10.0.0, project:setup.Cabal-1.8.0.6,
project:setup.Cabal-1.8.0.4, project:setup.Cabal-1.8.0.2,
project:setup.Cabal-1.6.0.3, project:setup.Cabal-1.6.0.2,
project:setup.Cabal-1.6.0.1, project:setup.Cabal-1.4.0.2,
project:setup.Cabal-1.4.0.1, project:setup.Cabal-1.4.0.0,
project:setup.Cabal-1.2.4.0, project:setup.Cabal-1.2.3.0,
project:setup.Cabal-1.2.2.0, project:setup.Cabal-1.2.1,
project:setup.Cabal-1.1.6, project:setup.Cabal-1.24.1.0 (constraint from
minimum version of Cabal used by Setup.hs requires >=3.4)
[__1] fail (backjumping, conflict set: project, project:setup.Cabal)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: project:setup.Cabal, project
What am I missing to get this to work? What should I do to compile my Haskell program?
Change your project.cabal to:
cabal-version: 3.4
name: project
version: 1.0
executable project
main-is: project.hs
build-depends:
base >= 4 && <= 5
, multimap
cabal-version: 3.4 picks the latest version of the Cabal package format, which should be fine to use given that you are using Cabal 3.4 already. Left unspecified, cabal-version defaults to a very old version (as in recent versions the field is mandatory), which makes the build-type field default to Custom rather than Simple. That, in turn, leads to the error you got, as described in cabal issue #5278. In addition, I have changed build-dependencies to build-depends, and containers to multimap (as the latter package is the one that provides Data.MultiMap).

Async library not present after installation

I'm trying to install async and it's proving to be an awful venture! I try to install it through cabal with the command cabal install async.
This gives me the error:
~/Desktop : cabal install async
Resolving dependencies...
Up to date
Warning: You asked to install executables, but there are no executables in
target: async. Perhaps you want to use --lib to install libraries instead.
Installing now with the command cabal install async --lib gives me the error :
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] next goal: base (user goal)
[__0] rejecting: base-4.14.1.0, base-4.14.0.0 (constraint from user target
requires ==4.13.0.0)
[__0] trying: base-4.13.0.0/installed-4.13.0.0
[__1] next goal: ghc (user goal)
[__1] rejecting: ghc-8.10.2, ghc-8.10.1 (constraint from user target requires
==8.8.3)
[__1] trying: ghc-8.8.3/installed-8.8.3
[__2] next goal: process (user goal)
[__2] rejecting: process-1.6.11.0 (constraint from user target requires
==1.6.10.0)
[__2] rejecting: process-1.6.10.0 (conflict: ghc =>
process==1.6.8.0/installed-1.6.8.0)
[__2] rejecting: process-1.6.9.0, process-1.6.8.2, process-1.6.8.1,
process-1.6.8.0/installed-1.6.8.0, process-1.6.8.0, process-1.6.7.0,
process-1.6.6.0, process-1.6.5.1, process-1.6.5.0, process-1.6.4.0,
process-1.6.3.0, process-1.6.2.0, process-1.6.1.0, process-1.6.0.0,
process-1.5.0.0, process-1.4.3.0, process-1.4.2.0, process-1.4.1.0,
process-1.4.0.0, process-1.3.0.0, process-1.2.3.0, process-1.2.2.0,
process-1.2.1.0, process-1.2.0.0, process-1.1.0.2, process-1.1.0.1,
process-1.1.0.0, process-1.0.1.5, process-1.0.1.4, process-1.0.1.3,
process-1.0.1.2, process-1.0.1.1, process-1.0.0.0 (constraint from user target
requires ==1.6.10.0)
[__2] fail (backjumping, conflict set: ghc, process)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: process, ghc, base
My process, ghc, and base are incompatible. I'm presuming it's because of the version constraints but when I try to install the package through the following commands, I get this message:
cabal get async
cd async-2.2.3
cabal build
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
In order, the following will be built (use -v for more details):
- async-2.2.3 (lib) (first run)
Configuring library for async-2.2.3..
Preprocessing library for async-2.2.3..
Building library for async-2.2.3..
[1 of 1] Compiling Control.Concurrent.Async ( Control/Concurrent/Async.hs, /Users/edward/Desktop/lsy/Olivia/async-2.2.3/dist-newstyle/build/x86_64-osx/ghc-8.8.3/async-2.2.3/build/Control/Concurrent/Async.o )
Control/Concurrent/Async.hs:215:1: warning: [-Wunused-imports]
The import of ‘Data.Semigroup’ is redundant
except perhaps to import instances from ‘Data.Semigroup’
To import instances alone, use: import Data.Semigroup()
|
215 | import Data.Semigroup (Semigroup((<>)))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When I go to actually import the library now, it says that its hidden and that the only way I can use it is if I expose but to expose it, I can only use the package within ghci rather than in programs such as those found here https://www.fpcomplete.com/haskell/library/async/
If it was able to build the library, shouldn't I "have" the library?

`cabal-install` refuses to solve conflicting `ghc` and `containers` versions

This repository contains a reproduction for an annoying error I got while using doctest in a test-suite.
cabal-installs solver fails to find a solution for this build-depends field using GHC 8.0.2:
build-depends:
base >= 4.7 && < 5
, doctest == 0.11.4
, containers == 0.5.10.2
Note that doctest depends transitively depends on ghc-8.0.2, which itself depends on containers-0.5.7.1, conflicting with my own constraints.
That's basically what cabal install is trying to tell me:
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
next goal: containers (dependency of repro-0.1.0.0)
rejecting: containers-0.5.7.1/installed-0.5... (conflict: repro =>
containers==0.5.10.2)
trying: containers-0.5.10.2
next goal: doctest (dependency of repro-0.1.0.0)
rejecting: doctest-0.13.0, doctest-0.12.0 (conflict: repro => doctest==0.11.4)
trying: doctest-0.11.4
next goal: ghc (dependency of doctest-0.11.4)
rejecting: ghc-8.0.2/installed-8.0... (conflict: containers==0.5.10.2, ghc =>
containers==0.5.7.1/installed-0.5...)
Dependency tree exhaustively searched.
Now, what bugs me is that stack install works just fine using lts-9 and an extra-deps for the containers version.
So in theory, cabal-install could also do 'the right thing' here. How can I tell it to?

Cabal sandbox is using a global dependency. Could not resolve

I'm trying to add timerep onto an existing application. I can't get it to resolve my dependencies. It looks like it is using the globally installed version of time == 1.4.2, when >= 1.5 would be ideal for my application.
How can I get cabal to use time 1.5? I've poked through unix, tls, process, timerep, and they all seem like they would work fine if it would just use time >= 1.5.
Here's the error:
serials> cabal install --only-dependencies
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: serials-0.1.0.2 (user goal)
trying: mandrill-0.2.2.0 (dependency of serials-0.1.0.2)
trying: http-client-tls-0.2.2 (dependency of mandrill-0.2.2.0)
trying: tls-1.2.17 (dependency of http-client-tls-0.2.2)
trying: x509-validation-1.5.2 (dependency of tls-1.2.17)
trying: process-1.2.0.0/installed-487... (dependency of x509-validation-1.5.2)
next goal: unix (dependency of process-1.2.0.0/installed-487...)
rejecting: unix-2.7.0.1/installed-299... (conflict: unix =>
time==1.4.2/installed-bf9..., serials => time>=1.5)
rejecting: unix-2.7.1.0, 2.7.0.1, 2.7.0.0, 2.6.0.1, 2.6.0.0, 2.5.1.1, 2.5.1.0,
2.5.0.0, 2.4.2.0, 2.4.1.0, 2.4.0.2, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.0,
2.3.0.0, 2.2.0.0, 2.0 (conflict: process => unix==2.7.0.1/installed-299...)
Dependency tree exhaustively searched.
Cabal file:
-- Initial serials.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
name: serials
version: 0.1.0.2
synopsis: serials
description: serials
license: MIT
license-file: LICENSE
author: Sean Hess
maintainer: Sean Hess
-- copyright:
category: Web Scraper
build-type: Simple
extra-source-files: README.md
cabal-version: >=1.10
Source-repository head
type: git
location: git#github.com:seanhess/serials.git
executable serials
main-is: Main.hs
hs-source-dirs: server
ghc-options: -fcontext-stack=36
-- other-modules:
-- other-extensions:
default-language: Haskell2010
build-depends:
base >=4.7 && <5,
tagsoup,
text,
scalpel,
containers,
network-uri,
monad-loops,
wreq,
lens,
bytestring,
parsec,
utf8-string,
tagsoup,
xml,
feed,
regex-pcre,
aeson,
network,
wai,
wai-extra,
wai-cors,
wai-middleware-static,
warp,
servant-server >= 0.4,
rethinkdb >= 1.16,
transformers,
either,
unordered-containers,
mtl,
http-types,
safe,
hashable,
resource-pool,
time >= 1.5,
pooled-io,
shelly,
string-conversions,
bcrypt,
random,
jwt,
cookie,
entropy,
mandrill == 0.2.2.0,
email-validate,
blaze-markup,
blaze-html,
iso8601-time,
scotty == 0.10.0,
timerep >= 2.0.0
It is difficult for cabal-install to produce a complete description of the mutual incompatibilities of an installation problem. It instead decides to print the first path to failure.
However, it prints Dependency tree exhaustively searched. which indicates that there actually is no solution to the given problem.
One thing that often helps is to look at the choices cabal-install has made, find one that seems suboptimal, and then add an explicit constraint to change that. This may result in a better error message.
Let's try [note that I'm not sure if I have exactly the same package DB as you have, so it may produce different results on your system].
You had (modulo hashes of installed packages):
$ cabal install --only-dependencies
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: serials-0.1.0.2 (user goal)
trying: mandrill-0.2.2.0 (dependency of serials-0.1.0.2)
trying: http-client-tls-0.2.2 (dependency of mandrill-0.2.2.0)
trying: tls-1.2.17 (dependency of http-client-tls-0.2.2)
trying: x509-validation-1.5.2 (dependency of tls-1.2.17)
trying: process-1.2.0.0/installed-06c... (dependency of x509-validation-1.5.2)
next goal: unix (dependency of process-1.2.0.0/installed-06c...)
rejecting: unix-2.7.0.1/installed-f86... (conflict: unix =>
time==1.4.2/installed-9b3..., serials => time>=1.5)
rejecting: unix-2.7.1.0, 2.7.0.1, 2.7.0.0, 2.6.0.1, 2.6.0.0, 2.5.1.1, 2.5.1.0,
2.5.0.0, 2.4.2.0, 2.4.1.0, 2.4.0.2, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.0,
2.3.0.0, 2.2.0.0, 2.0 (conflict: process => unix==2.7.0.1/installed-f86...)
Dependency tree exhaustively searched.
Looking through this, the error occurs with unix, which is a dependency of process. So the installed instance of process being chosen leads to trouble. So what if we disallow choosing that instance of process?
$ cabal install --only-dependencies --constraint="process source"
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: serials-0.1.0.2 (user goal)
next goal: time (dependency of serials-0.1.0.2)
rejecting: time-1.4.2/installed-9b3... (conflict: serials => time>=1.5)
trying: time-1.5.0.1
next goal: rethinkdb (dependency of serials-0.1.0.2)
rejecting: rethinkdb-1.16.0.0 (conflict: time==1.5.0.1, rethinkdb =>
time==1.4.*)
rejecting: rethinkdb-1.15.2.1, 1.15.2.0, 1.15.1.0, 1.15.0.0, 1.8.0.5, 1.8.0.4,
1.8.0.3, 1.8.0.2, 1.8.0.1, 1.8.0.0, 0.1.0.0 (conflict: serials =>
rethinkdb>=1.16)
Dependency tree exhaustively searched.
Aha! So rethinkdb, which is a direct dependency of serials, has an explicit dependency on time == 1.4.*. This is in direct conflict with the dependency of serials on time >= 1.5.
This is not easy to fix. You either need to make rethinkdb work with the newer time library, or serials with the older.
We enter the realm of speculation now: It is possible, but not guaranteed, that rethinkdb actually works with a newer version of time. We can try to instruct cabal-install to consider such install plans:
$ cabal install --only-dependencies --allow-newer=time
This actually yields an install plan on my machine. I have not tried building it, and I don't know whether it works. But it may be worth a try.

Resources