[Distutils] latest setuptools appears to require six in a breaking way

[Chris Withers]

On 25/01/2017 16:44, Matthias Bussonnier wrote:
> AFAICT this is not really an issue as this is on the release notes:
>
> https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0

Just because it's on the release notes doesn't mean its not an issue.

>> #581: Instead of vendoring the growing list of dependencies that Setuptools requires to function, Setuptools now requires these dependencies just like any other project. Unlike other projects, however, Setuptools cannot rely on setup_requires to demand the dependencies it needs to install because its own machinery would be necessary to pull those dependencies if not present (a bootstrapping problem). As a result, Setuptools no longer supports self upgrade or installation in the general case. Instead, users are directed to use pip to install and upgrade using the wheel distributions of setuptools.

For such a fundamental part of the python packaging ecosystem, that's a 
pretty disappointing change. Not supporting self-upgrade seems like a 
pretty massive regression, and the problems here are a result.

None of the problems I've had involve explicit installation of 
setuptools, it seems to be dragged in as a dependency somewhere along 
the way. The lack of ability to self-update in that situation is going 
to cause major pain.

>  >As discovered in #940, not all versions of pip will successfully
> install Setuptools from its pre-built wheel. If you encounter issues
> with “No module named six” or “No module named packaging”, especially
> following a line “Running setup.py egg_info for package setuptools”,
> then your pip is not new enough.

Right, so what's the recommended one-step way to set up a virtualenv now 
in Py 2.6-3.6?

>> There’s an additional issue in pip where setuptools is upgraded concurrently with other source packages, described in pip #4253. The proposed workaround is to always upgrade Setuptools first prior to upgrading other packages that would upgrade Setuptools.

That workaround is quite painful if you maintain any number of libraries 
that have CI scripts that will need to be hacked up to support the 
workaround and then reverted after the issue is finally fixed.

Sorry if this comes across as negative, I know it's not always easy to 
judge the outcome of changes before a big release, but I do hope 
something can be done to mitigate the pain of library maintainers doing 
the right thing and running CI...

cheers,

Chris