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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
