[Distutils] PEP 517 again

C Anthony Risinger c at anthonyrisinger.com
Sat Aug 26 16:47:05 EDT 2017

On Aug 26, 2017 2:17 PM, "Nathaniel Smith" <njs at pobox.com> wrote:

> [removed Guido from CC]
> On Aug 26, 2017 02:29, "Paul Moore" <p.f.moore at gmail.com> wrote:
> On 26 August 2017 at 03:17, Guido van Rossum <guido at python.org> wrote:
> > In pretty much any other context, if you have an operation that returns
> an
> > regular value or an error value, the error value should be None.
> (Exceptions
> > include e.g. returning a non-negative int or -1 for errors, or True for
> > success and False for errors.)
> So, given that build_sdist returns the path of the newly built sdist,
> the correct way to signal "I didn't manage to build a sdist" would be
> to return None.
> Now that it's put this way, it seems glaringly obvious to me that this
> is the correct thing to do.
> 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.

Why does the frontend need to know why an sdist was not created?

Frontend is asking the backend, given the current state of the world, to
either produce an sdist, or not. Sans ahead-of-time knowledge (see below),
I would expect build_sdist to make some sanity checks about the world, then
make a binary choice about whether sdist creation is a valid goal. If not
possible, return None or NotImplemented or False or dict-of-reasons or
whatever. Only if creation was *attempted*, and in the exceptional event it
then failed, would I expect an Exception. We don't have structured
exceptions sadly so they can't really carry much useful information from a
protocol perspective above and beyond a simple None or the like anyway.

I'd personally like to see some parity between build_sdist and build_wheel
in this regard. Maybe the disconnect here is we have a way to specify hard
reqs for building a wheel, statically or dynamically, and build_wheel is
expected to never fail, but no way to specify hard reqs needed for
build_sdist, necessitating this optional signaling path?

If we had some definitive way for the frontend to know ahead of time if
build_sdist is even expected to work, it could be called with more

This could be a new sdist-related key in [build-system], a new table like
[sdist-system].requires, or making the get_requires_for_* less optional,
and defaulting to None instead of [ ].

Frontend is responsible for prepping the world, so if it can't get a list
of reqs, somehow, for build_sdist, it knows it can't work. Same for
build_wheel, because you have to specify the backend itself, so there is at
least one requirement!

Thus if you are a backend that can produce an sdist without additional
requirements beyond build reqs, you should explicitly return empty list
from get_requires_for_build_sdist.


C Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170826/c8b11ed1/attachment-0001.html>

More information about the Distutils-SIG mailing list