> I do think the test case given in the bug report seems contrived. A number of packages are necessarily installed using apt to set up the environment; but then setuptools is specifically pulled from pip instead of from the Ubuntu archive? Why? Is there a test case that can be used to demonstrate the problem without what seems an unnatural mix of apt and pip?
I think a more common scenario where this would come up is:
It's pretty common to upgrade setuptools inside a virtualenv to the latest version. And possibly required to install newer packages in a virtualenv.
virtualenv downloads the latest setuptools by default, upstream. But we adjust it to prefer the bundled wheels in the archive.
We worked hard to ensure that our Python packages support a wide range of setuptools versions by including _distutils_system_mod that has code paths for all the versions we think are plausible to use (including the latest version).
> I do think the test case given in the bug report seems contrived. A number of packages are necessarily installed using apt to set up the environment; but then setuptools is specifically pulled from pip instead of from the Ubuntu archive? Why? Is there a test case that can be used to demonstrate the problem without what seems an unnatural mix of apt and pip?
I think a more common scenario where this would come up is:
$ virtualenv --system- site-packages foo require( 'distro- info')"
$ foo/bin/python -m pip install -U setuptools
$ foo/bin/python -c "import pkg_resources; pkg_resources.
It's pretty common to upgrade setuptools inside a virtualenv to the latest version. And possibly required to install newer packages in a virtualenv.
virtualenv downloads the latest setuptools by default, upstream. But we adjust it to prefer the bundled wheels in the archive.
We worked hard to ensure that our Python packages support a wide range of setuptools versions by including _distutils_ system_ mod that has code paths for all the versions we think are plausible to use (including the latest version).