New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong version of vector-instances selected #1875

Closed
snoyberg opened this Issue May 19, 2014 · 11 comments

Comments

Projects
None yet
6 participants
@snoyberg
Collaborator

snoyberg commented May 19, 2014

I'm not sure if this really is a dependency solver bug or not, but I'm opening the issue anyway to provide the information in case it's useful. Feel free to close the issue if it doesn't provide any helpful data.

From an empty package database and a recently run cabal update, with GHC 7.6.3 and cabal-install 1.16.0.2, I just ran:

$ cabal install conduit-combinators --dry-run

Which resulted in:

Resolving dependencies...
In order, the following would be installed (use -v for more details):
base16-bytestring-0.1.1.6
base64-bytestring-1.0.0.1
dlist-0.7.0.1
primitive-0.5.3.0
random-1.0.1.1
tagged-0.7.2
text-1.1.1.2
blaze-builder-0.3.3.2
hashable-1.2.2.0
nats-0.2
scientific-0.3.2.0
attoparsec-0.11.3.4
system-filepath-0.4.11
system-fileio-0.3.13
transformers-0.4.1.0
mmorph-1.0.3
mtl-2.2.0.1
exceptions-0.6.1
parsec-3.1.5
network-2.5.0.0
transformers-base-0.4.2
monad-control-0.3.3.0
lifted-base-0.2.2.2
resourcet-1.1.2.2
transformers-compat-0.3
contravariant-0.6
distributive-0.4.4
unix-compat-0.4.1.1
unordered-containers-0.2.4.0
semigroups-0.14
comonad-4.2
dlist-instances-0.1
semigroupoids-4.0.2
vector-0.10.9.1
mwc-random-0.13.1.1
vector-algorithms-0.6.0.1
vector-instances-0.0.2.1
mono-traversable-0.6.0
chunked-data-0.1.0.1
void-0.6.1
conduit-1.1.2.1
zlib-0.5.4.1
streaming-commons-0.1.2.4
conduit-extra-1.1.0.3
conduit-combinators-0.2.5.2

The selection of the old vector-instances-0.0.2.1 does not actually compile with vector-0.10.9.1. To address this, I tried to constrain the version of vector-instances by running:

$ cabal install conduit-combinators --dry-run --constraint 'vector-instances==3.3'

Which resulted in:

Resolving dependencies...
cabal: Could not resolve dependencies:
trying: conduit-combinators-0.2.5.2
trying: resourcet-1.1.2.2
trying: mtl-2.2.0.1
trying: mono-traversable-0.6.0
trying: vector-instances-3.3
trying: keys-3.10
rejecting: free-4.7.1, 4.7, 4.6.1, 4.6, 4.5, 4.4, 4.2, 4.1, 4.0 (conflict:
mtl==2.2.0.1, free => mtl>=2.0.1.0 && <2.2)
rejecting: free-3.4.2, 3.4.1, 3.4, 3.3.1, 3.3.0.2, 3.3.0.1, 3.3, 3.2, 3.1.1,
3.1, 3.0, 2.2, 2.1.1.1, 2.1.1, 2.1, 2.0.3, 2.0.2, 2.0.1.1, 2.0.1, 2.0,
1.8.0.4, 1.8.0.3, 1.8.0.1, 1.8.0, 0.2.3, 0.2.2, 0.2.1, 0.2.0, 0.1.1, 0.1.0
(conflict: keys => free>=4 && <5)

Ultimately, adding in --max-backjumps=-1 resulted in a working build plan:

$ cabal install conduit-combinators --dry-run --constraint 'vector-instances==3.3' --max-backjumps=-1
Resolving dependencies...
In order, the following would be installed (use -v for more details):
base16-bytestring-0.1.1.6
base64-bytestring-1.0.0.1
data-default-class-0.0.1
dlist-0.7.0.1
prelude-extras-0.4
primitive-0.5.3.0
random-1.0.1.1
stm-2.4.3
tagged-0.7.2
text-1.1.1.2
blaze-builder-0.3.3.2
hashable-1.2.2.0
nats-0.2
scientific-0.3.2.0
attoparsec-0.11.3.4
system-filepath-0.4.11
system-fileio-0.3.13
transformers-0.3.0.0
mmorph-1.0.3
mtl-2.1.3.1
exceptions-0.6.1
parsec-3.1.5
network-2.5.0.0
transformers-base-0.4.2
monad-control-0.3.3.0
lifted-base-0.2.2.2
resourcet-1.1.2.2
transformers-compat-0.1.1.1
contravariant-0.5.1
distributive-0.4.3.2
unix-compat-0.4.1.1
unordered-containers-0.2.4.0
semigroups-0.14
comonad-4.2
dlist-instances-0.1
semigroupoids-4.0.2
bifunctors-4.1.1.1
pointed-4.0
profunctors-4.0.4
free-4.7.1
keys-3.10
vector-0.10.9.1
mwc-random-0.13.1.1
vector-algorithms-0.6.0.1
vector-instances-3.3
mono-traversable-0.6.0
chunked-data-0.1.0.1
void-0.6.1
conduit-1.1.2.1
zlib-0.5.4.1
streaming-commons-0.1.2.4
conduit-extra-1.1.0.3
conduit-combinators-0.2.5.2

Pinging @ekmett. I think that restrictive upper bounds in some other packages may be what's confusing cabal-install. And it also seems that upper bounds in older versions of vector-instances may have prevented this, but as we know now there's no mechanism to make that after-the-fact.

@snoyberg

This comment has been minimized.

Collaborator

snoyberg commented May 19, 2014

Note that this bug report was sent to me by a user, I've just cleaned it up a bit and added extra information. Point being: it's affecting people in the real world now, and the only workaround I can provide is telling users to include --constraint 'vector-instances>=3.3'.

@kosmikus

This comment has been minimized.

Contributor

kosmikus commented May 19, 2014

I'd say it's not a bug, although I agree the behaviour is unfortunate. The problem is that for cabal-install, it's basically impossible to know that a build plan that's technically ok does in practice not work. The only thing that would help there is to use the .cabal file update feature on Hackage and make constraints more precise after the fact.

The max-backjumps limit then is a bit arbitrary. We've already increased it.

I have some vague ideas to speed up the solver. If I manage to implement them anytime soon (e.g. at ZuriHac), then it might be feasible to actually let the solver run and look for several install plans (rather than being happy if just one is found). Now, once we actually have more than one install plan, I think there are probably some rather good heuristics we can apply to determine which one the user would actually prefer (and even if we can't do it automatically, we can have cabal-install report to the user that there are several options and let them pick one).

@ekmett

This comment has been minimized.

Member

ekmett commented May 19, 2014

I went back and at least flagged the ancient < 0.1 versions as deprecated in hackage. Not sure how much that will help though.

@tibbe

This comment has been minimized.

Member

tibbe commented May 19, 2014

Unfortunately not much, as the way the solver users these depredations is
not very helpful. It probably ought to apply them as hard constraints in a
first solver pass and fallback to use the as soft preferences if that
fails. Today deprecating a package has essentially no (predictable) effect
on packages that are dependencies of other packages (i.e. the preferences
only really apply to the packages you mention directly on the cabal install
command line).

We're currently at a point where packages without upper bounds "poison"
Hackage in a currently unrecoverable way (i.e. releasing new versions with
added bounds doesn't fix the issue). We need to solve this issue soon, as
it's becoming a big problem. The main approach we're pursuing (/cc
@dcoutts) is to allow post facto modification of .cabal files on Hackage.
Other than that I'm considering disallowing (or at least warning about)
uploading packages without upper bounds.

On Mon, May 19, 2014 at 11:20 AM, Edward Kmett notifications@github.comwrote:

I went back and at least flagged the ancient < 0.1 versions as deprecated
in hackage. Not sure how much that will help though.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1875#issuecomment-43481209
.

@ekmett

This comment has been minimized.

Member

ekmett commented May 19, 2014

That is what I was afraid of.

Sent from my iPhone

On May 19, 2014, at 6:11 AM, Johan Tibell notifications@github.com wrote:

Unfortunately not much, as the way the solver users these depredations is
not very helpful. It probably ought to apply them as hard constraints in a
first solver pass and fallback to use the as soft preferences if that
fails. Today deprecating a package has essentially no (predictable) effect
on packages that are dependencies of other packages (i.e. the preferences
only really apply to the packages you mention directly on the cabal install
command line).

We're currently at a point where packages without upper bounds "poison"
Hackage in a currently unrecoverable way (i.e. releasing new versions with
added bounds doesn't fix the issue). We need to solve this issue soon, as
it's becoming a big problem. The main approach we're pursuing (/cc
@dcoutts) is to allow post facto modification of .cabal files on Hackage.
Other than that I'm considering disallowing (or at least warning about)
uploading packages without upper bounds.

On Mon, May 19, 2014 at 11:20 AM, Edward Kmett notifications@github.comwrote:

I went back and at least flagged the ancient < 0.1 versions as deprecated
in hackage. Not sure how much that will help though.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1875#issuecomment-43481209
.


Reply to this email directly or view it on GitHub.

@kosmikus

This comment has been minimized.

Contributor

kosmikus commented May 19, 2014

Independently of whether the solver's handling of constraints is helpful or not, I'd argue that deprecating single versions is the wrong thing to do in this situation. That's really only helpful if the package is in principle usable, but for some reason almost always worse than another.

Deprecating a version is a global thing. Just because a version doesn't work well, for example, with ghc-7.8.2 isn't a good reason to deprecate it.

Here, it seems we have a situation where a package is incompatible with certain other things, but that's not recorded in its dependencies. So it would be better to actually add more precise dependencies to the package in question (e.g., precise version constraints on base). Deprecating a version of a package completely could better be performed by adding an unsolvable constraint on base. Such constraints are actual (hard) constraints, not (soft) preferences, and would automatically be handled correctly by the solver.

@tibbe

This comment has been minimized.

Member

tibbe commented May 19, 2014

I agree that fixing the dependencies is the best things to do in this case.
(Ab)using the deprecation mechanism is really only something we tried to
try to remedy the situation short term.

On Mon, May 19, 2014 at 1:09 PM, kosmikus notifications@github.com wrote:

Independently of whether the solver's handling of constraints is helpful
or not, I'd argue that deprecating single versions is the wrong thing to do
in this situation. That's really only helpful if the package is in
principle usable, but for some reason almost always worse than another.

Deprecating a version is a global thing. Just because a version doesn't
work well, for example, with ghc-7.8.2 isn't a good reason to deprecate
it.

Here, it seems we have a situation where a package is incompatible with
certain other things, but that's not recorded in its dependencies. So it
would be better to actually add more precise dependencies to the package in
question (e.g., precise version constraints on base). Deprecating a
version of a package completely could better be performed by adding an
unsolvable constraint on base. Such constraints are actual (hard)
constraints, not (soft) preferences, and would automatically be handled
correctly by the solver.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1875#issuecomment-43489584
.

@ekmett

This comment has been minimized.

Member

ekmett commented May 19, 2014

Is it actually possible to retroactively change the dependencies on old versions like that? I was under the impression that that feature had never been turned on.

@tibbe

This comment has been minimized.

Member

tibbe commented May 19, 2014

The feature exists but is not working probably. I believe @dcoutts is
working on fixing it.

On Mon, May 19, 2014 at 3:30 PM, Edward Kmett notifications@github.comwrote:

Is it actually possible to retroactively change the dependencies on old
versions like that? I was under the impression that that feature had never
been turned on.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1875#issuecomment-43502982
.

@kosmikus

This comment has been minimized.

Contributor

kosmikus commented May 19, 2014

Oh, I was under the impression somehow that it was already working. But it seems there are still open issues ...

@23Skidoo

This comment has been minimized.

Member

23Skidoo commented Mar 7, 2016

Since post-release .cabal updates are now implemented, I'm closing this.

@23Skidoo 23Skidoo closed this Mar 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment