[Distutils] PEP 517 again

[xoviat]

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 at anthonyrisinger.com> wrote:

> On Aug 26, 2017 2:17 PM, "Nathaniel Smith" <njs at pobox.com> wrote:
>
>> [removed Guido from CC]
>>
>> On Aug 26, 2017 02:29, "Paul Moore" <p.f.moore at gmail.com> wrote:
>>
>> On 26 August 2017 at 03:17, Guido van Rossum <guido at 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170826/9a1b7bb1/attachment.html>