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 Tue, Aug 22, 2017, 09:14 Jim Fulton <j...@jimfulton.info> wrote: > 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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
