On 27 June 2018 at 15:59, Pradyun Gedam <pradyunsg@gmail.com> wrote:
>
> On Sun, Jun 24, 2018 at 8:20 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>> On 23 June 2018 at 07:47, Pradyun Gedam <pradyunsg@gmail.com> wrote:
>> > On Sat, 23 Jun 2018, 03:08 Brett Cannon, <brett@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   |   ncoghlan@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).

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.

​

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.

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

> 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