Re: [Distutils] PEP 517: Bootstrapping setuptools

On 22.08.2017 15:23, Daniel Holth wrote: > 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. when will we have a split out pkg-resources?

Re: [Distutils] PEP 517: Bootstrapping setuptools

On 23 August 2017 at 01:37, Nick Coghlan wrote: > [...] > > Bootstrapping self-hosted packaging tools is a genuinely hard problem > True, but on the other hand, it's the self-hosted packaging tools' own problem. It's up to the tools themselves to solve it. if PEP 517 simply

Re: [Distutils] PEP 517: Bootstrapping setuptools

On Wed, Aug 23, 2017, at 05:37 AM, Nick Coghlan wrote: > On 23 August 2017 at 05:24, xoviat wrote: > > The question that I have is: how does flit address this issue? Does flit > > require external dependencies to bootstrap itself? > > It does, but those dependencies currently

Re: [Distutils] PEP 517: Bootstrapping setuptools

On 23 August 2017 at 05:24, xoviat wrote: > The question that I have is: how does flit address this issue? Does flit > require external dependencies to bootstrap itself? It does, but those dependencies currently use setuptools as their packaging system rather than flit.

Re: [Distutils] PEP 517: Bootstrapping setuptools

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

Re: [Distutils] PEP 517: Bootstrapping setuptools

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 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

Re: [Distutils] PEP 517: Bootstrapping setuptools

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? 2017-08-22 10:23 GMT-05:00 Jim Fulton : > I didn't mention (nor do I recall anyone mentioning) venvs. > > Jim

Re: [Distutils] PEP 517: Bootstrapping setuptools

I didn't mention (nor do I recall anyone mentioning) venvs. Jim On Tue, Aug 22, 2017 at 11:15 AM, Matt Joyce wrote: > venvs within venvs... terrifying concept. > > On Tue, Aug 22, 2017 at 11:02 AM, Jim Fulton wrote: > >> >> >> On Tue, Aug 22, 2017 at

Re: [Distutils] PEP 517: Bootstrapping setuptools

venvs within venvs... terrifying concept. On Tue, Aug 22, 2017 at 11:02 AM, Jim Fulton wrote: > > > On Tue, Aug 22, 2017 at 9:23 AM, Daniel Holth wrote: > >> Isn't this a special case of needing . on sys.path when building a >> package? Then the same

Re: [Distutils] PEP 517: Bootstrapping setuptools

On Tue, Aug 22, 2017 at 9:23 AM, Daniel Holth 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

Re: [Distutils] PEP 517: Bootstrapping setuptools

Hi, On Mon, Aug 21, 2017 at 5:39 PM, xoviat 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

Re: [Distutils] PEP 517: Bootstrapping setuptools

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

Re: [Distutils] PEP 517: Bootstrapping setuptools

On Mon, Aug 21, 2017 at 5:39 PM, xoviat 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

Re: [Distutils] PEP 517: Bootstrapping setuptools

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

Re: [Distutils] PEP 517: Bootstrapping setuptools

On Mon, Aug 21, 2017 at 5:17 PM, xoviat 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 >

Re: [Distutils] PEP 517: Bootstrapping setuptools

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. 2017-08-21 16:05 GMT-05:00 xoviat : >

[Distutils] PEP 517: Bootstrapping setuptools

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