Why does the frontend need to know why an sdist was not created? I was of the opinion that such a distinction is not necessary because building a source distribution doesn't take that much time. However Donald thought that there needed to be a distinction because of the wasted time in attempting to build a wheel that was going to fail anyway. One of the things to consider is that site cythonizing takes time and maybe called for building source distribution. However since I think we're of the agreement that a source distribution should be as close to a checkout as possible, that may not be an issue because cythonizing may not be required to build the sdist.
On Aug 26, 2017 3: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? > > 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 > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig