[Distutils] PEP 517 again

[Paul Moore]

On 26 August 2017 at 20:17, Nathaniel Smith <njs at pobox.com> wrote:
> Eh... I would really prefer something that's (a) more explicit about what
> specifically went wrong, and (b) harder to return by accident. It's not at
> all obvious that if the list of requirements is 'None' that means 'this
> build supports making sdists in general but cannot make them from this
> source tree but might still be able to make a wheel'. And if you forget to
> put in a return statement, then python returns None for you, which seems
> like it could lead to some super confusing error modes.

Well, we've had an extensive discussion about how frontends need to
trust backends to get things right. I don't really see it as
reasonable to now argue that backends might "forget" to return the
right value - they might just as well "forget" to properly isolate
builds...

As regards an explicit description of what went wrong, why can't we
just use the same reporting methods that we will for any other build
issue (backends simply report the problem on stdout/stderr)? I don't
see why the backend has to package up its error information and send
it to the frontend to report, when we already have a perfectly
effective way for backends to report errors and/or warnings to the
user. If you're worried that the frontend might suppress the
information (maybe because it's planning on falling back to a direct
wheel build) then isn't that just the converse - backends need to
trust frontends to do the right thing?

It's hard to come up with convincing counterarguments to hypothetical
concerns. Do you have a specific scenario that worries you? I see
"return the path, or None indicating you couldn't build the sdist" as
a nice, simple solution. If there's a case we know of right now where
it's *too* simple, then let's understand the specifics - otherwise,
why not defer worrying about it for now? We can revise the PEP later
if experience shows we missed something.

Paul