I also think that Guido pretty much ruled out Notimplemented. On Aug 26, 2017 4:04 PM, "xoviat" <xov...@gmail.com> wrote:
> 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