<div dir="auto">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. <div dir="auto"><br></div><div dir="auto">For building, the name returned indicates building was possible, but it's not truthily equivalent to none.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Aug 27, 2017 12:08 AM, "C Anthony Risinger" <<a href="mailto:c@anthonyrisinger.com">c@anthonyrisinger.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 26, 2017 at 11:18 PM, xoviat <span dir="ltr"><<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="m_-7451849872996968761gmail-">> <span style="font-size:12.8px">and they do not appear to receive the source or wheel directories.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">The source directory is the current directory, if I am not mistaken.</span></div></div></blockquote><div><br></div><div>Oh right right, for some reason I was reading the `build_*` hooks as receiving the input <span style="font-size:12.8px">directory</span> rather than the output <span style="font-size:12.8px">directory</span>. I don't see it stated anywhere that the PWD will be the source directory however. Might be a good addition.</div><div><br></div>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).</div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="m_-7451849872996968761gmail-"><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span></div></span><div>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.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="m_-7451849872996968761gmail-"><div> <span style="font-size:12.8px">def get_requires_for_build_sdist(</span><span style="font-size:12.8px">s<wbr>ource_dir, ...):</span><br></div><div style="font-size:12.8px">    # I have no interest in sdists and I never will.</div><div style="font-size:12.8px">    # GO AWAY.</div><div style="font-size:12.8px">    return None</div><div style="font-size:12.8px"><br></div></span><div style="font-size:12.8px">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:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">def build_sdist(...):  # Indicates success</div><div style="font-size:12.8px">    return "x.tar.gz"</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><span style="font-size:12.8px">def build_sdist(...):  # Indicates failure</span><br></div><div style="font-size:12.8px"><div style="font-size:12.8px">    return None</div><div><br></div><div><br></div><div>Those are not truthily equivalent, which is important because it means that someone is unlikely to make a mistake on that matter.</div></div></div></blockquote><div><br></div><div>What is the difference? Both equally inform the frontend that building an sdist is not going to happen.</div><div><br></div><div>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.</div><div><br></div><div>-- </div><div><br></div></div><div class="m_-7451849872996968761gmail_signature">C Anthony</div>
</div></div>
</blockquote></div></div>