Skip to content
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

Cannot handle complex requirement resolution #174

Closed
vbabiy opened this issue Mar 15, 2011 · 12 comments
Closed

Cannot handle complex requirement resolution #174

vbabiy opened this issue Mar 15, 2011 · 12 comments
Labels
auto-locked Outdated issues that have been locked by automation C: dependency resolution About choosing which dependencies to install type: bug A confirmed bug or unintended behavior

Comments

@vbabiy
Copy link
Contributor

vbabiy commented Mar 15, 2011

Not only does pip not check for conflicts as noted in http://bitbucket.org/ianb/pip/src/tip/pip/req.py#cl-928, it doesn't consider any requirements on a package other than the first. So if I have

  • A requires B and C
  • B requires D<=1.1
  • C requires D<=0.9

installing A will give us D==1.1 rather than D==0.9


@vbabiy
Copy link
Contributor Author

vbabiy commented Mar 15, 2011

Resolving version dependencies among inter-dependent packages is a complex
(but well-understood) problem. Pip will need to deal with these issues. I
suggest stealing the solver algorithm used by aptitude.


Original Comment By: Dave Abrahams

@vbabiy
Copy link
Contributor Author

vbabiy commented Mar 15, 2011

Tarek told me that this issue is covered in a ticket at
http://bugs.python.org, but I can't find it. I'd like to at least see a
cross-reference here before this ticket is closed.


Original Comment By: Dave Abrahams

@vbabiy
Copy link
Contributor Author

vbabiy commented Mar 15, 2011

Here's a cross-reference: http://bugs.python.org/issue8927. Until
responsibility for this functionality is resolved we should keep this ticket
open.


Original Comment By: Dave Abrahams

@vbabiy
Copy link
Contributor Author

vbabiy commented Mar 15, 2011

  1. Does pip install D==1.1 silently, or error out?

  2. I am just curious if there is a real-world example you know of this
    dependency? (I know that 'launchpadlib' indirectly depends on two versions of
    'martian' - but not sure if pip installs the expected version of 'martian').


Original Comment By: Sridhar Ratnakumar

@vbabiy
Copy link
Contributor Author

vbabiy commented Mar 15, 2011

Sridhar, there are lots of examples of such dependency conflicts in Debian
packages ; I think I recall some Python examples but I have no pointer handy.

Dave, I think it’s the responsibility of distutils2 to handle this. I’m afraid
we can’t look at Aptitude here, since it is under the GPL and
Python/distutils2 is not. However, reading documentation or papers is
possible.

I suggest keeping to bugs.python.org now.


Original Comment By: Éric Araujo

@vbabiy
Copy link
Contributor Author

vbabiy commented Mar 15, 2011

Éric: I agree that it's probably a distutils2 thing. However, in light of the
response to http://groups.google.com/group/the-fellowship-of-the-
packaging/browse_frm/thread/22267799eba3d90e
, I don't see anything
happening over there

packaging/browse_frm/thread/22267799eba3d90e


Original Comment By: Dave Abrahams

@carljm
Copy link
Contributor

carljm commented Oct 26, 2011

This bug is apparently causing trouble on a regular basis with Pyramid installations and zope.interface pre-installed globally on OSX. See pull pypa/virtualenv#178

@benoitbryon
Copy link

Don't know if it helps, but zc.buildout (or maybe recipes like zc.recipe.egg?) can handle complex dependencies: it returns an error and says something like "I can't do that", which is what I expect.
So maybe the solution is in buildout's or zc.recipe.egg code.

Example I use, given sphinx requires docutils>=0.7:

pip: fail

pip install -r requirements.txt

where requirements.txt is :

sphinx==1.1.2
docutils==0.6

says

Successfully installed docutils Jinja2 Pygments sphinx

So we believe everything is ok, but...

>>>> sphinx-quickstart 
Traceback (most recent call last):
...
pkg_resources.DistributionNotFound: docutils>=0.7

Error! The install passes. The error is detected at runtime, which could be a long time later. The error message tells us that there is a dependency error, but we will have to investigate before we discover the "docutils==0.6" directive.

zc.buildout (or zc.recipe.egg): pass

Given the following buildout.cfg file:

[buildout]
parts = python
eggs =
    sphinx==1.1.2
    docutils==0.6

[python]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}

Let's run buildout:

>>>> bin/buildout 
Installing python.
While:
  Installing python.
Error: There is a version conflict.
We already have: docutils 0.6
but Sphinx 1.1.2 requires 'docutils>=0.7'.

Ok. The dependency conflict is detected early. The install fails. We are aware of the conflict.

@kennknowles
Copy link

+1 I have just run into something that is probably the same issue and was going to file a ticket.

Here is repo with a minimal and clear reproduction: https://github.com/kennknowles/pip-version-issue

@benoitbryon
Copy link

I guess this ticket should be tagged with "dependency resolution" label.

@qwcode
Copy link
Contributor

qwcode commented Sep 24, 2013

thanks, added the label.

@qwcode
Copy link
Contributor

qwcode commented Nov 7, 2013

closing as dupe to #988

@qwcode qwcode closed this as completed Nov 7, 2013
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: dependency resolution About choosing which dependencies to install type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

5 participants