On Mon, Aug 21, 2017 at 5:39 PM, xoviat <xov...@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). Jim > 2017-08-21 16:27 GMT-05:00 Jim Fulton <j...@jimfulton.info>: > >> >> >> On Mon, Aug 21, 2017 at 5:17 PM, xoviat <xov...@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. >> >> Jim >> >> >>> >>> 2017-08-21 16:05 GMT-05:00 xoviat <xov...@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 archive >>>> >>>> Viola! 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 >>> >>> >> >> >> -- >> Jim Fulton >> http://jimfulton.info >> > > -- Jim Fulton http://jimfulton.info
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
