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

setup_requires feature does not handle multiple versions #141

Closed
ghost opened this issue Jan 24, 2014 · 23 comments
Closed

setup_requires feature does not handle multiple versions #141

ghost opened this issue Jan 24, 2014 · 23 comments
Labels

Comments

@ghost
Copy link

@ghost ghost commented Jan 24, 2014

Originally reported by: marscher (Bitbucket: marscher, GitHub: marscher)


This seems somehow related to issue323 in distribute.

Why is a not met requirement not simply installed local as an egg and then inserted to path, if it is required via setup_requires?

Scenario:
system wide installation of package A, version 1.0 (which can not be upgraded as non administrative user)
setup_requires=[('A > 1.0')]

Instead of building A > 1.0 before the build process starts, pkg_resources throws a VersionConflict:

#!python

 File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 576, in resolve
    dist = best[req.key] = env.best_match(req, self, installer)
pkg_resources.VersionConflict: (numpy 1.6.2 (/usr/lib/pymodules/python2.7), Requirement.parse('numpy>=1.8'))

Is this behaviour intended? And if that is the case it should be somehow documented, because it is not intuitive.


@ghost
Copy link
Author

@ghost ghost commented Jan 24, 2014

Original comment by marscher (Bitbucket: marscher, GitHub: marscher):


It seems like this is a regression, since the changelog of version 0.6.31 states, that the linked issue 323 in distribute is fixed.

@ghost
Copy link
Author

@ghost ghost commented Jan 26, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


As reported in Distribute 323, the fix in 0.6.31 was rolled back in 0.6.32 due to Distribute 335. So while it's something of a regression, it's also intentional. I'd very much like to fix Distribute 323 and Distribute 335. Erik Bray lays out a plan moving forward. We should explore that.

@ghost
Copy link
Author

@ghost ghost commented Jan 26, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


It appears that Erik may have already applied the prescribed patch, so it may be possible now to re-apply the fix from Distribute 323.

@ghost
Copy link
Author

@ghost ghost commented Jan 27, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I've begun the work of restoring the patch. It's yet untested and might have emergent issues due to merge challenges, but feel free to try it out.

@ghost
Copy link
Author

@ghost ghost commented Jan 27, 2014

Original comment by marscher (Bitbucket: marscher, GitHub: marscher):


Thanks for the fast response!
I'am willing to test, but dont have access to your repo.

@ghost
Copy link
Author

@ghost ghost commented Jan 27, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I've updated the repo to be public.

@ghost
Copy link
Author

@ghost ghost commented Feb 6, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Backed out changeset: ef949e6e6de1, which was itself a backout of the fix for Distribute #323, so this backout restores that fix and also Fixes #141.

@ghost
Copy link
Author

@ghost ghost commented Feb 6, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I've uploaded a beta release of 2.2 to the downloads section. Please give it a try.

@ghost
Copy link
Author

@ghost ghost commented May 5, 2014

Original comment by marscher (Bitbucket: marscher, GitHub: marscher):


Thank you for the quick fix!

@ghost
Copy link
Author

@ghost ghost commented May 13, 2014

Original comment by embray (Bitbucket: embray, GitHub: embray):


Wow, totally forgot about this issue, but was led back to it today due to a new, related issue. I will open a new issue for this, but in short if two versions of the same package belonging to a namespace package are on two different sys.path entries, for example

sys.path = [
    ...,
    custom/path/to/foo.bar-0.1.egg,
    ...,
    site-packages/foo.bar-0.1.egg
]

if I import foo.bar this can sometimes result in the version in site-packages being imported rather than the version earlier in sys.path.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Issue #223 was marked as a duplicate of this issue.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by languitar (Bitbucket: languitar, GitHub: languitar):


For me, this issue still appears with setuptools 5.1, running with python 2.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I also still see this failing when using pytest-runner, which uses the same mechanism for loading dependencies early.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I believe there is an error in the logic:

https://bitbucket.org/pypa/setuptools/src/8c81a2ed47d597cda7812fceee96c76772242239/pkg_resources.py?at=default#cl-622

'env' is a function global, but is set based on the value of a single dist (the first one encountered). If that first dist is resolved within the current environment, then subsequent dists will also be resolved in that environment, even if they conflict.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


@embray It looks like more work is necessary to solve this issue in real-world projects.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by embray (Bitbucket: embray, GitHub: embray):


That reminds me, I still need to submit my fix for #207. I've been busy with work and got completely distracted from that. I'll see if I can resolve this.

I'm a little surprised though, since this fix resolved the issue for me.

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by embray (Bitbucket: embray, GitHub: embray):


Do you think it would fix it to use a different environment, in that while loop, for each distribution in the requirements? (at least if env=None was passed in to the function--otherwise it should look for all requirements in the same Environment, I think).

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2014

Original comment by embray (Bitbucket: embray, GitHub: embray):


This is a shot in the dark since I'm not exactly sure how best to reproduce the issue, but does this patch solve the issue?

@ghost
Copy link
Author

@ghost ghost commented Jun 22, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I apologize I haven't had a chance to look at this. I did look at it briefly a few days ago, and my instinct was to do the same - use an empty environment for each iteration. I'm yet unsure about the other consequences of that approach, but I'll look into that more later.

@ghost
Copy link
Author

@ghost ghost commented Jun 23, 2014

Original comment by embray (Bitbucket: embray, GitHub: embray):


I've never not been a bit confused about the different roles of Environment and WorkingSet. But if I understand correctly the Environment is mostly just for locating distributions, while the WorkingSet is a collection of currently active distributions. The same WorkingSet is being reused throughout, which I think is more important insofar as keeping track of which distributions are currently found.

@ghost
Copy link
Author

@ghost ghost commented Oct 7, 2014

Original comment by lmazuel (Bitbucket: lmazuel, GitHub: lmazuel):


Hi,

This bug is really annoying :(. I used 2 hours this morning to figure out why my jenkins did not want to compile but my personal laptop did...
In my case, if I wrote:

#!python

install_requires=["requests >= 2.4.1", "Flask >= 0.10.1"],

If Flask is installed on the system, it works (my laptop). If Flask is not (my jenkins), it fails with:

#!python

pkg_resources.VersionConflict: (requests 2.2.1 (/usr/lib/python3/dist-packages), Requirement.parse('requests>=2.4.1'))

In a debugger, I saw that resolve begins with "Flask" and depending of its presence (or not) in the system, set the env and ws the way requests install will fail or not...

I can pass through the bug using

#!python

install_requires=["Flask >= 0.10.1", "requests >= 2.4.1"],

Actually, puts the conflicting libs at the end makes resolve works since env and ws are None when needed.

Tested with setuptools 3.3 (ubuntu 14.04) and 6.0.2 (currently last from pip)

@ghost
Copy link
Author

@ghost ghost commented Jun 18, 2015

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I'm raising the priority on this one. Would someone be willing to present the submitted patch as a pull request? Due to their high visibility in the UI, a PR almost always forces a first-look when I find time to work on setuptools.

jaraco added a commit that referenced this issue Mar 29, 2016
@jaraco jaraco removed the 2.1 label Mar 31, 2016
@jaraco
Copy link
Member

@jaraco jaraco commented Nov 23, 2016

Based on the changelog and commit history, I believe this was fixed and released in 19.4.

@jaraco jaraco closed this Nov 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.