[Distutils] PEP 517 again

[xoviat]

The difference is that an empty list for requires would indicate that
building is possible but none would not. Those two values are truthily
equivalent.

For building, the name returned indicates building was possible, but it's
not truthily equivalent to none.

On Aug 27, 2017 12:08 AM, "C Anthony Risinger" <c at anthonyrisinger.com>
wrote:

> On Sat, Aug 26, 2017 at 11:18 PM, xoviat <xoviat at gmail.com> wrote:
>
>> > and they do not appear to receive the source or wheel directories.
>>
>> The source directory is the current directory, if I am not mistaken.
>>
>
> Oh right right, for some reason I was reading the `build_*` hooks as
> receiving the input directory rather than the output directory. I don't
> see it stated anywhere that the PWD will be the source directory however.
> Might be a good addition.
>
> In this case, `get_requires_for_*` hooks should also be able to depend on
> PWD being the applicable source directory (which of course might be an
> unpacked sdist like in pip's proposed multistage sdist -> unpack -> wheel
> pipeline).
>
>
>> > This lets `build_*` focus purely on building things straight away.
>> There is a difference between "no more reqs are needed to do X" and "no
>> possible req will achieve X" even though both add zero requirements. Why
>> not let this hook relay it's decision more completely?
>>
>> Not trying to speak on behalf of flit here, but if I understand
>> correctly, flit requires git to build a source distribution. Flit knows its
>> build requirements, so it can just return them when get_requires is called.
>> However, it needs to attempt to invoke git to find out whether it can build
>> a source distribution, which if I understand correctly, is a lengthy
>> operation (whether that's actually true is not actually relevant because we
>> are discussion potentially any backend/operation). It's more efficient if
>> git is only invoked once, and if a failure occurs, then under the proposal
>> "None" would be returned from build_sdist rather than the name of the built
>> source distribution.
>>
>
> What is the benefit in making `build_sdist` handle this assertion?
> Requirements checking is only performed once, earlier than building.
> Somewhere, somehow, something must look to see if git exists. Is it not
> more appropriate to check early, while asserting python requirements, vs.
> actually being told to build an sdist? That is already the expectation on
> the wheel side of things since it would also fail if necessary system
> binaries are missing. Checking for git is conflating system reqs and python
> reqs as "requirements", but I don't see why the get_requires_* hooks can't
> do both if they so choose.
>
>
>>  def get_requires_for_build_sdist(source_dir, ...):
>>     # I have no interest in sdists and I never will.
>>     # GO AWAY.
>>     return None
>>
>> I have to say that the above example is not a good idea. Perhaps I was a
>> bit muddled on that point earlier: the reason that "return None" is a good
>> idea for build sdist is, well:
>>
>> def build_sdist(...):  # Indicates success
>>     return "x.tar.gz"
>>
>> def build_sdist(...):  # Indicates failure
>>     return None
>>
>>
>> Those are not truthily equivalent, which is important because it means
>> that someone is unlikely to make a mistake on that matter.
>>
>
> What is the difference? Both equally inform the frontend that building an
> sdist is not going to happen.
>
> At the end of the day, I'm not too partial to any of the solutions I've
> read thus far, and do not have any desire to derail progress. I just don't
> like the variation in `build_sdist` vs. `build_wheel` because it feels like
> a kludge to me. I thought perhaps defaulting sdists to "unsupported" and
> requiring a backend to opt-in was both more elegant and more explicit,
> allowing tools like flit to better express their conditional sdist support.
>
> --
>
> C Anthony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170827/46aba3ba/attachment.html>