On Fri, Jun 16, 2017 at 11:28 PM, Donald Stufft <donald@stufft.io> wrote:
On Jun 16, 2017, at 11:08 PM, Nathaniel Smith <njs@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