<div dir="ltr">> <span style="font-size:12.8px">2. I'm not completely clear on how pip's implementation will work - I</span><br style="font-size:12.8px"><span style="font-size:12.8px">think the intention is to always build a sdist and build a wheel from</span><br style="font-size:12.8px"><span style="font-size:12.8px">that, unless the backend reports it can't build a sdist, in which case</span><br style="font-size:12.8px"><span style="font-size:12.8px">we ask it to build a wheel directly.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This was the exact process that I proposed, but was told that:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> I agree that the way you want to do packaging is fundamentally incompatible</span></div><div><span style="font-size:12.8px">with build systems that do not resemble distutils. Perhaps since this is</span></div><div><span style="font-size:12.8px">distutils sig some here are too used to distutils as the only model of how</span></div><div><span style="font-size:12.8px">packaging might work. Beware that, when fighting monsters, you yourself do</span></div><div><span style="font-size:12.8px">not become a monster... for when you gaze long into the abyss. The abyss</span></div><div><span style="font-size:12.8px">gazes also into you.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">There seems to be some miscommunication about the actual process being proposed. </span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-24 10:07 GMT-05:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 25 August 2017 at 00:51, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> 4. The point of all this is that the definition of build_directory<br>
> says "If build_directory is None, the backend may do an 'in place'<br>
> build which modifies the source directory and may produce different<br>
> results from those that would be obtained by exporting an sdist<br>
> first". That's the bit that bothers me a lot - if we lose<br>
> build_directory, we lose the option for pip to request that a backend<br>
> produce a wheel "equivalent to producing an sdist first". And that<br>
> capability is something I think pip should require[2]. I don't<br>
> particularly care who specifies the actual directory (as per your<br>
> comment, I thought someone else wanted this, for caching or something)<br>
> but I *do* care about telling backends we don't want "different<br>
> results from those that would be obtained by exporting an sdist<br>
> first".<br>
<br>
</span>That's a phrasing error in the PEP - ideally, backends should always<br>
produce consistent results regardless of whether or not the frontend<br>
builds an sdist first. What that phrasing was attempting to<br>
acknowledge is that actually ensuring sdist/wheel consistency may have<br>
some extra requirements (like the git CLI) that may not apply to the<br>
"just give me a usable wheel, I don't care whether it's publication<br>
quality or not" case.<br>
<br>
The key thing that changed my mind on whether or not we needed to<br>
include the build_directory parameter from the start was actually the<br>
NotImplementedError discussion: as soon as we permitted backends to<br>
raise NotImplementedError for any non-None build_directory setting,<br>
we'd effectively made supporting the feature optional.<br>
<br>
And if supporting the feature's going to be optional anyway, then the<br>
*whole point* of defining the backend API in Python rather than as a<br>
CLI was to make it easy for us to add new optional methods later,<br>
which means we can start without build_directory support, and if we<br>
find we miss it for some specific reason, then we can add it back as a<br>
suitably named optional method like "build_wheel_variant" (if the<br>
use-case is cross-compiling for multiple ABIs without clobbering<br>
intermediate artifacts), or "build_wheel_with_artifact_<wbr>cache" (if the<br>
use case is to allow the frontend to ask that the backend cache<br>
intermediate values in a particular place).<br>
<span class="im HOEnZb"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div>