Isn't this a special case of needing . on sys.path when building a package? Then the same version of setuptools that is being packaged builds itself.
I've experimented with a different kind of bootstrapping where pip installs setuptools on demand when the first setuptools requiring package is built. You kindof need pkg-resources as a separate package for this. It is a cool parlor trick but it's simpler and harmless to just always install setuptools like we do.
On Mon, Aug 21, 2017 at 5:39 PM, xoviat <xoviat@gmail.com> wrote:This statement comes from something that Donald said:> The unvendoring means that setuptools and the project code are now competing over who gets to define what an acceptable version is for these libraries to be installed with.As if this isn't going to be true for any other build system, and setuptools won't at all be in any way special in a PEP 517 world. So you are always going to have complaints about "well build system X required a newer version but my project requires an older version" when the real problem is that people are requiring an older version/ projects do not have a stable API.This boils down to implementation details. <shrug> pip dealt with this issue and buildout stumbled because of differences in the way they managed their paths. Buildout could have coped (eventually).Jim2017-08-21 16:27 GMT-05:00 Jim Fulton <jim@jimfulton.info>:On Mon, Aug 21, 2017 at 5:17 PM, xoviat <xoviat@gmail.com> wrote:Of course, to be frank, the principle failure with this plan is that third-party tools (buildout, os packagers) will not be compliant with PEP 517 even after it is adopted, and will then complain about having to update their build systems.I don't understand this statement. If buildout needs to be compliant, it will be (eventually). I can imagine a future where everything is distributed with wheels and buildout wouldn't need to build anything.Jim2017-08-21 16:05 GMT-05:00 xoviat <xoviat@gmail.com>:Previously, the attempt to move setuptools off of vendored dependencies failed because it was not done correctly: install_requires was set to the vendored dependencies but not setup_requires, which would have been required to correctly specify dependencies. However, setup_requires would have introduced circular dependencies that are impossible to correctly resolve, so that would have simply shifted an impossible problem onto pip.The principle issue then, is that setuptools requires setuptools to build itself. And although, this problem was previously not worth solving because of 'setup.py install', it is now not a difficult problem to solve if we rethink slightly what should be included in the setuptools respository:- Rather than re-generating egg_info on each setup.py invocation, we can cache dist-info in the setuptools respository.- We can implement a simple entry_points script that updates dist-info based on the contents of setup.py, which is only runnable of course after setuptools is installed- We can implement the reference build backend for setuptools: simply copy the files and dist-info into a new compliant zip archiveViola! Setuptools is no longer required to build setuptools, and the installation process is fully compliant with Python PEPs.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
--
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig