[Distutils] PEP 517 again

[xoviat]

I also think that Guido pretty much ruled out Notimplemented.

On Aug 26, 2017 4:04 PM, "xoviat" <xoviat at 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 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/b64b3749/attachment-0001.html>