<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 2:43 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10 February 2016 at 13:23, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> On 10 February 2016 at 20:53, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
>> We don't have to solve the whole "sdist 2.0" issue right now. Simply<br>
>> saying that in order to publish pypa.json-based source trees you need<br>
>> to zip up the source directory, name the file "project-version.zip"<br>
>> and upload to PyPI, would be sufficient as a short-term answer<br>
>> (assuming that this *would* be a viable "source file" that pip could<br>
>> use - and I must be clear that I *haven't checked this*!!!) </div></div></blockquote><div><br></div><div>This is exactly what pip itself does right now for "pip install .", so clearly it is viable.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">until<br>
>> something like Nathaniel's source distribution proposal, or a<br>
>> full-blown sdist-2.0 spec, is available. We'd need to support whatever<br>
>> stopgap proposal we recommend for backward compatibility in those new<br>
>> proposals, but that's a necessary cost of not wanting to delay the<br>
>> current PEP on those other ones.<br>
><br>
> One of the reasons I went ahead and created the specifications page at<br>
> <a href="https://packaging.python.org/en/latest/specifications/" rel="noreferrer" target="_blank">https://packaging.python.org/en/latest/specifications/</a> was to let us<br>
> tweak interoperability requirements as needed, without wasting<br>
> people's time with excessive PEP wrangling by requiring a separate PEP<br>
> for each interface affected by a proposal.<br>
><br>
> In this case, the build system abstraction PEP should propose some<br>
> additional text for<br>
> <a href="https://packaging.python.org/en/latest/specifications/#source-distribution-format" rel="noreferrer" target="_blank">https://packaging.python.org/en/latest/specifications/#source-distribution-format</a><br>
> defining how to publish source archives containing a pypa.json file<br>
> and the setup.py shim. </div></div></blockquote><div><br></div><div>The setup.py shim should be optional right? If a package author decides to not care about older pip versions, then the shim isn't needed.<br></div><div><br></div><div>Ralf<br><br></div></div><br></div></div>