On Aug 26, 2017 2:17 PM, "Nathaniel Smith" <n...@pobox.com> wrote:
> [removed Guido from CC] > > On Aug 26, 2017 02:29, "Paul Moore" <p.f.mo...@gmail.com> wrote: > > On 26 August 2017 at 03:17, Guido van Rossum <gu...@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 confidence. 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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
