Pipenv: Could not find a version that matches with latest version of Mypy and Pylint

Created on 27 Feb 2019  ·  13Comments  ·  Source: pypa/pipenv

Follow up of #2785 (and probably other).

Got the same good-old "resolver issue" again today:

  • pylint 2.3.0 was released today on Pypi.
  • pylint 2.3.0 wants astroid>=2.2.0
  • astroid 2.2.0 want typed-ast>=1.4.0

In my pipfile I also have pylint = "*" and mypy = "*".

And latest version of mypy want typed-ast<1.4.0. So the resolver on pipenv update --clear fails witht the infamous error:

Could not find a version that matches typed-ast<1.3.0,<1.4.0,>=1.3.1

In short: as of today, latest versions of mypy and pylint packages have incompatible dependencies.

Fixing by add this in the Pipfile:

pylint = "<2.3.0"
typed-ast = "<1.4.0,>=1.3.1"
astroid = "<2.2.0"

To prevent update of pylint.

I understand digging into the resolver is a really complex task, and I tried it and failed at doing anything relevant, but still, I hope one good lad here find time to dig into this and find a way to have pipenv finds itself it should not take the latest version of pylint package in this case, and try with a previous version.

Expected behavior:

  • pylint version is updated, the resolver fails at the end with "Could not find a version" error.
  • previous versions available on pypi is tried, and so on, until the same version that were on Pipfile.lock. If not present, a depth limit may be set to avoid to try every version of pylint package
  • even in case of failure, pipenv update --clear should end in success (providing the lock file is still coherent) but add an explicit warning telling 2 packages have incompatible dependency rule in their latest version available on Pypi.
Type

Most helpful comment

@gsemet
did you try to force to set mypy==0.660 in Pipfile?
I think after mypy pacakge updated in Feb 9, it's happening nowadays.

All 13 comments

To reproduce in the future, reproduce with this Pipfile:

[packages]
pylint = "<=2.3.0,>=2.2.0"
mypy = "==0.670"

Expected behavior:

  • resolver fails resolution on typed-ast, see that this dependency comes from astroid==2.2.0 and mypy==0.670.
  • magic happens here => resolver knows to try a different version of astroid and so a different version of pylint
  • resolver chooses pylint==2.2.2
  • resolver chooses astroid==2.1.0
  • resolver chooses mypy==0.670
  • original restriction from my Pipfile is still respected, but pylint can not be updated to latest available version.

Bitten by this too. See also https://github.com/pypa/pipenv/issues/3569.

@gsemet
did you try to force to set mypy==0.660 in Pipfile?
I think after mypy pacakge updated in Feb 9, it's happening nowadays.

Yes, freezing version does the job.

My point is that the pipenv's resolver should be able to find out the solution itself. Given the rule pylint = "<=2.3.0,>=2.2.0" and mypy = "==0.670", the solution pylint==2.2.2 is correct.

@gsemet Thanks for the efforts. Due to some limitations, piptools' resolver, which is used by pipenv doesn't have the ability as you said. The pipenv team has a brand new resolver implementation passa which can do this job. It will replace the current resolver in the future.

good :) Tell me if you need help for testing it

To confirm, is the below the official "solution" until passa is incorporated?

[packages]
pylint = "<=2.3.0,>=2.2.0"
mypy = "==0.660"

In my testing, that seems to work for Python 3.6.3, but not 3.7.1: https://travis-ci.org/bachya/pyflunearyou/builds/501245354

EDIT: @gsemet's original post is the combination that worked for me on all Python versions:

[packages]
astroid = "<2.2.0"
pylint = "<2.3.0"
typed-ast = "<1.4.0,>=1.3.1"

we have the OK to incorporate passa, but we have a lot of legwork to do first cleaning up other issues. The issue here is just that piptools doesn't _backtrack_ to resolve conflicts after it makes a decision. Passa handles that issue

Preliminary checks indicate that I can now use

astroid = "*"
pylint = "*"
typed-ast = "*"

Can this be closed?

Since the original issue was resolved, close it now.

yes, it can be closed

Indeed, the current incompatibility is solved, but the pipenv resolver is still not able to handle a similar situation in the future... hope the new version will support it, it is one of the big show stopper that makes people (not me, but some other) in my company not happy when I want to convince them to use pipenv. Even if bare “pip install” actually hides the issue (it does not crash because there is no big resolver, it is the lastest dependency that « wins » the game), at least it works and does not block them in their work

@gsemet Yes, this issue is only one of a large number of similar resolution issues in the backlog.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jeyraof picture jeyraof  ·  3Comments

jacek-jablonski picture jacek-jablonski  ·  3Comments

jacebrowning picture jacebrowning  ·  3Comments

bgjelstrup picture bgjelstrup  ·  3Comments

jakul picture jakul  ·  3Comments