[Distutils] Finishing up PEP 517

Nathaniel Smith njs at pobox.com
Sat Jun 17 03:07:23 EDT 2017


On Fri, Jun 16, 2017 at 11:28 PM, Donald Stufft <donald at stufft.io> wrote:
>>
>> On Jun 16, 2017, at 11:08 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> (because the legacy setup.py
>> command errors out, because the build_sdist hook is missing, because
>> the build_sdist hook errors out...); probably falling back on
>> shutil.copytree.
>
>
> Ah okay. This is where the disconnect was. I assumed if a project was using a PEP 517 build tool the result of a build_sdist failure (or a build_wheel failure) would be surfacing an error to the end user, not some sort of fallback.

What we might be able to get away with in the PEP 517 transition is to
provide an explicit way of signalling "build_sdist failed because
that's just not a supported operation", so that pip could distinguish
that from "something unexpected blew up" and only fall back in the
first case.

Obviously we want build_sdist to be supported in as many places as
possible, but given that we anticipate that there will be times when
it won't be (flit, or ad hoc build systems that just never implement
it) then I think having a standard way to communicate that is a good
idea regardless.

It's surprisingly tricky to come up with a good signal for this
though. We don't want to use a user-defined exception, because we
don't have like a "standard PEP 517 library" to put it in. We could
use a built-in exception like NotImplementedError, but then there's
the risk that that gets raised for some other reason  internally, it
leaks out, and then we misinterpret it as being an intentional signal.

Proposal: "NotImplemented" is a legal return value from build_sdist
(similar to dunder methods), and should trigger whatever fallback
behavior the frontend would do if the hook was simply undefined.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org


More information about the Distutils-SIG mailing list