You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 == in requirements.txt for reproducibility.
This usually means pip freeze --all > requirements.txt.
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).
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:
virtualenv upgrades pip / setuptools / wheel by default (new behaviour in 15)
setuptools unvendored dependencies (new in 34)
At least personally, the first behaviour is alarming and makes it very difficult to have repeatable builds (without scattering --no-download, VIRTUALENV_NO_DOWNLOAD=1 or PIP_INDEX_URL=... virtualenv all over our ~thousands of codebases). The second seems not a problem to me, I rather like that setuptools now acts more like a normal python package (though the pypa tools don't treat it as such: magically upgrading, excluding from freeze, etc.).
In short, big shrugs -- it might just be "unfortunate: won't fix" and that would be ok too!