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

Pip doesn't spot conflicting versions #775

Closed
Wilfred opened this issue Jan 22, 2013 · 4 comments
Closed

Pip doesn't spot conflicting versions #775

Wilfred opened this issue Jan 22, 2013 · 4 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@Wilfred
Copy link
Contributor

Wilfred commented Jan 22, 2013

If I create a dummy package -- here's /tmp/example_package/setup.py (note the requirements):

from distutils.core import setup

setup(name='my_project',
      description="Just a test project",
      version="1.0",
      py_modules=['sample'],
      install_requires=['requests > 0.12'])

Here's /tmp/example_package/sample.py:

import requests

def get_example():
    return requests.get("http://www.example.com")

Now, I create a virtualenv:

$ virtualenv /tmp/foobar --distribute -p python2.7
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in /tmp/foobar/bin/python2.7
Also creating executable in /tmp/foobar/bin/python
Installing distribute.................................................................................................................................................................................................done.
Installing pip................done.
$ source /tmp/foobar/bin/activate

I create a requirements.pip with conflicting requirements:

# this requires requests > 0.12:
file:///tmp/example_package

# but this conflicts:
requests==0.9.0

Pip happily installs this:

$ pip install -r requirements.pip                                                                                                                                                                       [18:40:10]
Unpacking ./example_package
  Running setup.py egg_info for package from file:///tmp/example_package

Downloading/unpacking requests==0.9.0 (from -r requirements.pip (line 3))
  Downloading requests-0.9.0.tar.gz (55Kb): 55Kb downloaded
  Running setup.py egg_info for package requests

Downloading/unpacking certifi>=0.0.4 (from requests==0.9.0->-r requirements.pip (line 3))
  Downloading certifi-0.0.8.tar.gz (118Kb): 118Kb downloaded
  Running setup.py egg_info for package certifi

Installing collected packages: requests, my-project, certifi
  Running setup.py install for requests

  Running setup.py install for my-project

  Running setup.py install for certifi

Successfully installed requests my-project certifi
Cleaning up...

Is this a bug? My example_package won't work, because its requirements aren't met.

@qwcode
Copy link
Contributor

qwcode commented Jan 27, 2013

currently, pip is written such that requirements in the requirements file win out, period (and for other dependencies, it's first version found, wins as well)

should/could it be smarter? at least be aware and inform of this situation? I think so, but it's not right now.

there was a thread related to this on distutils-sig recently
http://mail.python.org/pipermail/distutils-sig/2012-November/019255.html

@piotr-dobrogost
Copy link

Is this lack of detection of conflicting requirements only due to use of requirements file? I'm observing the same behavior when passing specifications on command line like
pip -vvv install pylons==0.9.7 routes==1.5 (see my post at https://groups.google.com/forum/#!topic/python-virtualenv/fKLNbwvruTw).
Pip version 1.5.2

I guess that's what @qwcode meant by

(and for other dependencies, it's first version found, wins as well)

If so then maybe we should change the title of this issue to more general statement Pip doesn't spot conflicting versions.?

@Wilfred
Copy link
Contributor Author

Wilfred commented Feb 5, 2014

@piotr-dobrogost agreed, I've changed the title.

@qwcode
Copy link
Contributor

qwcode commented Feb 5, 2014

#988 is the main issue for this now. closing this as a dupe.

@piotr-dobrogost see the #988 description. if that's still not clear, respond over there, and I'll try to improve it.

@qwcode qwcode closed this as completed Feb 5, 2014
msabramo pushed a commit to msabramo/pip that referenced this issue Dec 22, 2014
This command ensures that all packages installed have all the
requirements they need, and that requirements have compatible
versions. This is useful because pip can install incompatible
dependencies[1], or a user may have manually (un)installed a
package.

[1] pypa#775
msabramo pushed a commit to msabramo/pip that referenced this issue Mar 8, 2015
This command ensures that all packages installed have all the
requirements they need, and that requirements have compatible
versions. This is useful because pip can install incompatible
dependencies[1], or a user may have manually (un)installed a
package.

[1] pypa#775
@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
Projects
None yet
Development

No branches or pull requests

3 participants