On Sat, Aug 26, 2017 at 1:47 PM, C Anthony Risinger <c...@anthonyrisinger.com> wrote: > 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?
This whole discussion is about handling a specific case: suppose you have a frontend like pip that when given a source directory and asked to build a wheel, wants to implement that as: - build sdist - unpack sdist - build wheel from unpacked sdist And suppose you have a backend like flit, that can build sdists from some source directories (e.g. VCS checkouts) but not others (e.g. unpacked sdists). We need some way for pip and flit to negotiate that even though pip *normally* would implement its build-a-wheel operation by first building an sdist, in this case it's ok to silently fall back to some other strategy (like building the wheel directly in the source tree, or manually copying the source tree somewhere else and then building a wheel in it). But, we don't want this fallback behavior to hide real bugs. So if the backend says "look, I just can't do sdists here, and that's an expected thing, it's not something where the user needs to take any particular action like filing a bug report or fixing their system or anything like that, so if you have an alternative way to accomplish what you're trying to do then you should just silently discard this error and try that", ...cool. But if it doesn't explicitly say that, then we don't want to silently discard the error and do something else. It's taken a *lot* of back and forth to reach consensus that all we need here is some special error signal from the *_sdist operations. Let's focus on resolving that :-) > 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? Not sure what you mean about hard reqs. The reason for the lack of parity is that we don't currently have any use cases where build_wheel is expected to fail, but this is expected in some sense (not sure what that would even mean), and there's some fallback that the frontend may want to invoke instead. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
