setup_requires feature does not handle multiple versions

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.

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/141

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.

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.

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.

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.

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.

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

---

I've updated the repo to be public.

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.

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.

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

---

Thank you for the quick fix!

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.

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

---

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

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

---

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

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.

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.

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

---

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