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