<div dir="ltr">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. </div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-21 16:05 GMT-05:00 xoviat <span dir="ltr"><<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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:</div><div>- Rather than re-generating egg_info on each setup.py invocation, we can cache dist-info in the setuptools respository.</div><div>- 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</div><div>- We can implement the reference build backend for setuptools: simply copy the files and dist-info into a new compliant zip archive</div><div><br></div><div>Viola! Setuptools is no longer required to build setuptools, and the installation process is fully compliant with Python PEPs. </div></div>
</blockquote></div><br></div>