The OP was about "bootstrapping setuptools." If, as Leonardo said, we only isolate on the first level (requirements from install_requires or user will be isolated but requirements from build_requires will share the same environment as the invoker of build_requires if they are not wheels), then that opens up some interesting possibilities. However, I don't necessarily think that this is a good idea because it opens up situations that could be nasty to debug.
I still think the simpler method would be as I have said previously, to have a very minimal backend that doesn't depend on anything and simply archives the files and info. We can even put this backend into a separate package that requires and depends on nothing, so that future build systems don't have to re-invent the wheel here. The question that I have is: how does flit address this issue? Does flit require external dependencies to bootstrap itself? 2017-08-22 13:50 GMT-05:00 Jim Fulton <j...@jimfulton.info>: > Oh, gawd. From now on, someone will have to say buildout 3 times before I > appear. > > On Tue, Aug 22, 2017 at 2:06 PM, xoviat <xov...@gmail.com> wrote: > >> So are we going for a "primarily isolation" approach then where builds >> are only isolated on the first level, but subsequent levels share the same >> build environment? >> > > I'm a huge fan of isolation, but isolation seems to me to be orthogonal to > this discussion. > > I'm done with this thread. :) > > Jim > > >> >> 2017-08-22 10:23 GMT-05:00 Jim Fulton <j...@jimfulton.info>: >> >>> I didn't mention (nor do I recall anyone mentioning) venvs. >>> >>> Jim >>> >>> >>> On Tue, Aug 22, 2017 at 11:15 AM, Matt Joyce <m...@nycresistor.com> >>> wrote: >>> >>>> venvs within venvs... terrifying concept. >>>> >>>> On Tue, Aug 22, 2017 at 11:02 AM, Jim Fulton <j...@jimfulton.info> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Aug 22, 2017 at 9:23 AM, Daniel Holth <dho...@gmail.com> >>>>> wrote: >>>>> >>>>>> 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. >>>>>> >>>>> No. The issue for us it wasn't setuptools itself, but it's >>>>> dependencies and those dependencies conflicted with dependencies of of >>>>> packages we were installing *and* those packages importing these >>>>> dependences (indirectly) in their setup scripts. Setup scripts that >>>>> import >>>>> the thing they're about to install, generally to get the version :(, is >>>>> something I'd love to see go away. >>>>> >>>>> Jim >>>>> >>>>> -- >>>>> Jim Fulton >>>>> http://jimfulton.info >>>>> >>>>> _______________________________________________ >>>>> Distutils-SIG maillist - Distutils-SIG@python.org >>>>> https://mail.python.org/mailman/listinfo/distutils-sig >>>>> >>>>> >>>> >>> >>> >>> -- >>> Jim Fulton >>> http://jimfulton.info >>> >>> _______________________________________________ >>> Distutils-SIG maillist - Distutils-SIG@python.org >>> https://mail.python.org/mailman/listinfo/distutils-sig >>> >>> >> > > > -- > Jim Fulton > http://jimfulton.info >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
