Well it turns out that my app name is the same as one of the packages that is uploaded to hackage, so when I try to resolver extra dependencies using stack solver --resolver lts 7.12, I get the following error:
$ stack solver --resolver lts-7.12
Using configuration file: stack.yaml
Using cabal packages:
- html-parse.cabal
Using resolver: lts-7.12
Using compiler: ghc-8.0.1
Asking cabal to calculate a build plan...
Trying with packages from lts-7.12 as hard constraints...
Attempt failed.
>>>> Cabal errors begin
cabal.exe: Could not resolve dependencies:
next goal: html-parse (user goal)
rejecting: html-parse-0.2.0.0, 0.1.0.0 (global constraint requires ==0.0.0.3)
trying: html-parse-0.0.0.3
next goal: hunit (dependency of html-parse-0.0.0.3)
Dependency tree exhaustively searched.
<<<< Cabal errors end
Could not parse cabal-install errors:
>>>> Cabal errors begin
cabal.exe: Could not resolve dependencies:
next goal: html-parse (user goal)
rejecting: html-parse-0.2.0.0, 0.1.0.0 (global constraint requires ==0.0.0.3)
trying: html-parse-0.0.0.3
next goal: hunit (dependency of html-parse-0.0.0.3)
Dependency tree exhaustively searched.
<<<< Cabal errors end
My app/package name in .cabal file is html-parse and the current version is 0.0.0.3. It looks like my own package is listed as a dependency with a constraint of ==0.0.0.3, but there is another pacakge on hackage that has the same name but different versions.
Can I somehow solve this issue without renaming my own app?
Quoting the Cabal user guide (emphasis mine):
Package names and versions
All packages have a name, e.g. “HUnit”. Package names are assumed to be unique. Cabal package names can use letters, numbers and hyphens, but not spaces. The namespace for Cabal packages is flat, not hierarchical.
Accordingly, the Cabal library doesn't have a feature for handling package name conflicts, and neither do cabal-install nor stack. That being so, you will have to rename your package.
P.S.: I am deliberately not considering seriously the possibility of setting up your project to use a private Hackage that excludes the homonymous package, both because I don't know how it would play out in practice and because it is vastly more trouble than it is worth.
Related
I'm currently trying to build a Haskell project using nix-shell and cabal, with alex and happy as build tools. Building inside nix-shell (with and without --pure), I get the following strange error message:
cabal: Could not resolve dependencies:
[__0] trying: aoc-0.1.0.0 (user goal)
[__1] unknown package: aoc:happy:exe.happy (dependency of aoc)
[__1] fail (backjumping, conflict set: aoc, aoc:happy:exe.happy)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: aoc, aoc:happy:exe.happy
It appears to be trying to satisfy some nonsense dependency aoc:happy:exe.happy, despite no reference to such a thing in the cabal file. Within the nix-shell, I am able to run alex and happy directly as executables, as they have been provided by nix.
Question: Does anyone know what I might be able to try to resolve this? I would like to try to provide dependencies completely using nix, instead of using cabal update to download packages from Hackage.
The source code can be found in the branch unhappy here, with files of interest:
package.yaml (for hpack)
aoc.cabal
default.nix
Some things I've tried so far are:
I found a similar-looking error here, but it was not fully resolved, and the nix build there was using haskell.nix.
I've tried the following other build methods while troubleshooting:
Building with cabal/ghc installed through ghcup (cabal 3.2.0.0, ghc 8.10.2): the build succeeds—alex and happy are fetched from Hackage and run successfully as build-tools.
Building with nix-build: the build runs successfully (without packages being fetched to .cabal). callCabal2nix recognizes alex and happy, and provides them successfully to cabal.
Building within nix-shell with cabal update: the same as 1. occurs and it succeeds, as nix's provided cabal fetches the packages from Hackage, but this is not what I'm trying to accomplish.
I've also tried using nix-shell to build a minimal example alex/happy project, using the same generic *.nix files from my own project, with the same errors being produced.
Cabal simply isn't convinced that alex is installed by Nixpkgs' custom Haskell environment (the .env attribute on the package that you correctly use for the shell).
If you run cabal update, cabal-install will be able to install alex and happy the way it wants and continue to build your project.
$ cabal v2-build
[... omitted ...]
[__0] trying: aoc-0.1.0.0 (user goal)
[__1] unknown package: aoc:happy:exe.happy (dependency of aoc)
[__1] fail (backjumping, conflict set: aoc, aoc:happy:exe.happy)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: aoc, aoc:happy:exe.happy
$ cabal update
Downloading the latest package list from hackage.haskell.org
$ cabal v2-build
Resolving dependencies...
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):
- alex-3.2.6 (exe:alex) (requires download & build)
- happy-1.20.0 (exe:happy) (requires download & build)
- aoc-0.1.0.0 (lib) (configuration changed)
- aoc-0.1.0.0 (exe:aoc) (dependency rebuilt)
Downloading happy-1.20.0
[... omitted ...]
Configuring library for aoc-0.1.0.0..
Preprocessing library for aoc-0.1.0.0..
Building library for aoc-0.1.0.0..
[... omitted ...]
According to the Cabal build-tools documentation the field has been deprecated and removed. It seems like you'll be better off with build-tool-depends.
build-tool-depends:
alex:alex >=3.2.5 && <3.3
, happy:happy >=1.20.0 && <1.21
I am experiencing trouble with proto-lens library on GHC 8.10.
It has not been supported. Team fixed issue, but didn't published update on Hackage and I am trying to pull the fix just from github tag.
I don't see any difference in building process after added following section to stack.yaml
allow-newer: true
extra-deps:
- github: google/proto-lens
commit: 0bef8c2f3da645f068b8a26ac168c1da41608182
subdirs: proto-lens
I guess I missed something.
It is not clear for me how Stack sees this custom dependency.
Where is association that it is source for proto-len?
What if I made a typo in subdirs or url?
So Stack could get something else and it could be even a correct Stack library, but not proto-lens.
Log of failing build
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.0.2.0 supports
'ghc' version < 8.10): /opt/ghc/8.10.1/bin/ghc is version 8.10.1
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: megaexample-0.4.2 (user goal)
[__1] trying: base-4.14.0.0/installed-4.1... (dependency of megaexample)
[__2] trying: opentelemetry-extra-0.4.2 (user goal)
[__3] next goal: proto-lens (dependency of opentelemetry-extra)
[__3] rejecting: proto-lens-0.6.0.0 (conflict:
base==4.14.0.0/installed-4.1..., proto-lens => base>=4.10 && <4.14)
[__3] rejecting: proto-lens-0.5.1.0, proto-lens-0.5.0.1, proto-lens-0.5.0.0,
proto-lens-0.4.0.1 (conflict: base==4.14.0.0/installed-4.1..., proto-lens =>
Another supplementary question: where is library version in Stack specified?
Stack starts with 0.6, but there is no such literal in the source tree.
Link to source
Should I tweak cabal file also?
The proto-lens library is referenced in cabal file.
executable eventlog-to-opentelemetry
import: options
main-is: Main.hs
hs-source-dirs: exe/eventlog-to-opentelemetry
other-modules: Console, Json, Resource, Attribute, Spans
build-depends:
aeson,
base,
bytestring,
clock,
filepath,
microlens,
microlens-th,
opentelemetry >= 0.4.0,
opentelemetry-extra,
opentelemetry-proto,
optparse-applicative,
proto-lens,
text,
unordered-containers,
default-language: Haskell2010
Log of failing build
That error log is from cabal, not stack. cabal doesn't read stack.yaml, but cabal.project.
Here is the relevant part of cabal's documentation to specify remote dependencies: Cabal user manual
stack wouldn't try different versions of packages. The stack.yaml file specifies package versions upfront: every package is set to at most one specific version, either via extra-deps (where you specify individual packages explicitly) or resolver (which is a whole set of specific package versions, that you can browse on https://stackage.org).
I guess I missed something. It is not clear for me how Stack sees this custom dependency. Where is association that it is source for proto-len? What if I made a typo in subdirs or url? So Stack could get something else and it could be even a correct Stack library, but not proto-lens.
It is indeed strange that doesn't seem to have an option to explicitly name the expected remote packages. This is an issue worth bringing up to stack maintainers.
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.
I am totally new to Haskell an cabal and I'm trying to make yesod work.
My cabal version is cabal-install version 1.20.0.3
using version 1.20.0.2 of the Cabal library
This is what happends when I tru to install alex:
$ cabal install alex
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: alex-3.1.4 (user goal)
next goal: QuickCheck (dependency of alex-3.1.4)
rejecting: QuickCheck-2.8.1, 2.8 (global constraint requires ==2.7.6)
trying: QuickCheck-2.7.6
next goal: transformers (dependency of QuickCheck-2.7.6)
rejecting: transformers-0.4.3.0, 0.4.2.0, 0.4.1.0, 0.3.0.0, 0.2.2.1, 0.2.2.0,
0.2.1.0, 0.2.0.0, 0.1.4.0, 0.1.3.0, 0.1.1.0, 0.1.0.1, 0.1.0.0, 0.0.1.0,
0.0.0.0, 0.4.0.0 (global constraint requires installed instance)
Dependency tree exhaustively searched.
Second attempt:
$ cabal install alex happy yesod-bin --allow-newer
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: alex-3.1.4 (user goal)
trying: QuickCheck-2.7.6/installed-1a8... (dependency of alex-3.1.4)
trying: tf-random-0.5/installed-ef3... (dependency of
QuickCheck-2.7.6/installed-1a8...)
next goal: primitive (dependency of tf-random-0.5/installed-ef3...)
rejecting: primitive-0.5.0.1/installed-8e5... (global constraint requires
==0.6)
rejecting: primitive-0.6 (conflict: tf-random =>
primitive==0.5.0.1/installed-8e5...)
rejecting: primitive-0.5.4.0, 0.5.3.0, 0.5.2.1, 0.5.1.0, 0.5.0.1, 0.5, 0.4.1,
0.4.0.1, 0.4, 0.3.1, 0.3, 0.2.1, 0.2, 0.1 (global constraint requires ==0.6)
Dependency tree exhaustively searched.
What do I have to do to install alex?
A related question is this one:
cabal install --- global constraint requires installed instance
The comment by #kosmikus on that question is:
So the Stackage LTS config file contains the constraint transformers
installed, meaning that only an already present version of
transformers can be used. This is reasonable, because GHC ships with a
specific version of transformers. For ghc-7.8, this is
transformers-0.3.0.0. For some reason, this installed version is not
considered by cabal-install. Your partial log doesn't contain
sufficient info to see why.
How can I fix my Stackage LTS config file? Where is it on Ubuntu?
Try this cabal install alex --allow-newer
The reason of the problem was that my GHC was too old. I downloaded a newer version and solved the problem.
Failed (and wrong) attempt
You should have a cabal.config file in your current directory. Open it with any text editor and serach for the transformers installed string.
Once you have found it, replace it with transformers ==0.4.3.0 or any other version you like.
It is a bad solution, because, as dfeurer writes:
transformers sits very far down in the package dependency structure. I
believe it depends only on base; I imagine a large majority of
packages on Hackage depend, directly or indirectly, on it. If you
upgrade transformers, practically every dependency in the system will
go screwy, which is the opposite of what you're going for if you're
using Stackage.
Clean solution by Sibi
Use the stackage packages as it is. If you have some global package causing problem, then remove them and use stackage exclusively. Also using sandbox for each project is a good idea.
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.