On Wed, Jun 27, 2018 at 9:15 PM Paul Moore <p.f.mo...@gmail.com> wrote:
> On 27 June 2018 at 15:59, Pradyun Gedam <pradyu...@gmail.com> wrote: > > > > On Sun, Jun 24, 2018 at 8:20 AM Nick Coghlan <ncogh...@gmail.com> wrote: > >> > >> On 23 June 2018 at 07:47, Pradyun Gedam <pradyu...@gmail.com> wrote: > >> > On Sat, 23 Jun 2018, 03:08 Brett Cannon, <br...@python.org> wrote: > >> >> The JSON schema is for "illustrative purposes only", so it should not > >> >> be > >> >> viewed as part of the spec. > >> > > >> > Yeah, that's exactly what I pointed out to the user in the pip issue > >> > tracker > >> > as well. > >> > >> Something you may want to consider is that while PEP 518 explicitly > >> specifies that a missing pyproject.toml should be interpreted as > >> "build-system.build-requires=['setuptools', 'wheel']", there's nothing > >> that specifically prohibits an installer from offering a > >> "default-for-missing-build-requires" setting. > >> > >> Right now, `pip` effectively defaults that hypothetical setting to > >> "['setuptools', 'wheel']", with the proposed change being to switch it > >> to "[]" instead (which better aligns with the intent of PEP 518). > >> > >> However, the new semantics mean that some sdist releases of some > >> projects will become uninstallable. Making the installer level setting > >> explicit rather than hypothetical would allow anyone affected to deal > >> with that problem without either being stuck on the older version of > >> pip, or being forced to concurrently upgrade to newer versions of the > >> affected projects. > >> > >> Cheers, > >> Nick. > >> > >> -- > >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > > > > > > Assuming we are going to disallow missing build-requires, > > I think a better way for this would be to allow a user to override > > build-requires on a per-package basis. It'd be a more verbose > > and also clearer about which packages are needing some sort > > of work-around to install, pushing packages to just directly > > specify build-requires in future releases. > > I'm not sure what you're suggesting here (but I suspect it's a > pip-specific implementation detail rather than a standards issue). Now that I think about it, yeah. Sorry for the noise! > But > > there are three separate cases to consider: > > 1. Project has pyproject.toml with build-system.requires specified. No > problem, full PEP 518 behaviour (and pip uses build isolation). > 2. Project has pyproject.toml but no build-system.requires, Illegal, > confirmed by this discussion, so terminate with an error (pip currenly > warns, but will move to an error after a deprecation period). > 3. Project has no pyproject.toml. Old-style project, PEP 518 says that > the default is [setuptools, wheel]. Pip will actually use the legacy > (no build isolation) code path, which is a backward compatibility > choice. I'm not actually sure PEP 518 needs to even comment on this > case, as such projects clearly don't conform to that PEP and tools > like pip will of necessity have to handle them as "legacy". > > The only case where I can see your "per-package overrides" fitting in > would be (3), which is outside the scope of PEP 518 and so really a > pip-only issue. > > I am suggesting it for (2). I'll elaborate on the tracker. But if you're saying that the end user, when > installing (from source) a package that has no pyproject.toml, can say > something like "instead of just installing setuptools and wheel, > install A, B, anc C", then > > a) A, B and C had better include setuptools and wheel, or we're hosed, > b) We're on the legacy path, so we're not actually using build > isolation (and so we're not able to install anything), > c) I'm not sure I see why the end user would want to override what the > project expected anyway. > > I'm pretty sure I've missed something here. I suggest we move this > discussion to a feature request on the pip tracker, where you can > explain your proposal in a bit more detail. > Indeed. > > This is already a feature request for pip for a different use case > > and I think it's a reasonable request. > > What's the issue number? I don't recall seeing anything like this. > https://github.com/pypa/pip/issues/4582 > Sure, it is extra hoops to jump through but in the long term it > > makes things fairly frictionless since everyone will start > > specifying build-system.requires -- if there's a missing > > build-system.requires, use the override mechanism to use > > setuptools and wheel (and anything else possibly) to build it. > > I don't see how this (an end user feature) will encourage projects to > move to using pyproject.toml - it seems like the opposite is more > likely. > Paul >
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/YJL65VRPGTG4EURCSGXC4LKX6OT3VJFZ/
