Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Setuptools 34.0.2 breaks new virtual envs with six < 1.10 #947
This change to setuptools was made intentionally in order to avoid the ugly hacks and complicated bootstrapping scenarios imposed by such hacks.
The issue here is that the offending packages that are requiring old versions of six. They simply are no longer compatible with setuptools.
Those failing packages accepted the burden of incompatibility with any package that declared a later six dependency when they pinned their dependency to a specific version. Since those packages are demanding an old version of six, then it should be those packages that either vendor six themselves or adapt to support newer versions of six.
I did look into the possibility of expanding the supported six versions in setuptools. If I change the version to 1.6.0, some integration tests start to fail (because stevedore depends on six 1.9), but otherwise the tests pass. Perhaps setting a lower lower bound will be viable and save some headaches.
In applications, it is a best practice to pin every dependency with
This usually means
If one were to generate a requirements.txt with an older version of six / pyparsing / etc. they're now suddenly broken as virtualenv downloads the newest version of setuptools (demonstrated in pypa/virtualenv#1009).
That's a good question!
In an ideal world, pip wouldn't upgrade setuptools to a version that conflicts with already installed dependencies (and would do dependency resolution) but I don't think that's really something that's doable without making pip way more intelligent and way slower.
It's possible this is just an "unfortunate" combination of two separate "unfortunate" decisions, notably:
At least personally, the first behaviour is alarming and makes it very difficult to have repeatable builds (without scattering
In short, big shrugs -- it might just be "unfortunate: won't fix" and that would be ok too!