<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 28, 2017 at 12:20 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> interface). So if pip calls build_sdist and then build_wheel, there will be<br>
> two source distributions built (one by pip and one by setuptools) before<br>
> building a wheel.</span></blockquote><div><br></div><div>exactly why pip should NOT concern itself with the sdist -- either the back end needs to do it anyway, or it doesn't need to do it at all, and would only be doing so to satisfy pip.</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">This is precisely the question - whose responsibility is it to ensure<br>
that sdist->wheel vs build_wheel equivalence is maintained? The PEP<br>
says it's the backend's responsibility, so pip shouldn't need to do<br>
anything.<br></blockquote><div><br></div><div>makes sense to me. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But, we're currently having debates about "return None" which hinge on<br>
"if backends have bugs, return None might not work well". Sure - but<br>
if backends have bugs, they may not maintain wheel equivalence.</blockquote><div><br></div><div>If backends have bugs (and they will), any number of things can go wrong. Making the spec so that front ends can have a better idea what went wrong is a fine idea, but it can only go so far.</div><div><br></div><div>The only thing we really need to distinguish is " that functionality is not implemented" from "something went wrong"</div><div><br></div><div>And not even that if we don't have pip trying to go through some machinations about what do if the back-end does not produce a sdist.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> To that extent, I'm with Donald - pip going<br>
sdist->wheel protects the user against the known-to-be-an-issue bug<br>
that the backend doesn't ensure wheel equivalence.</blockquote><div><br></div><div><div>pip can not protect the user from a poorly written back-end. And it shouldn't try.</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Chris Barker has pointed out that backends have no reason to support<br>
sdists now.<br></blockquote><div><br></div><div>not quite -- the reason to support sdist is because you want an sdist, not because it's a necessary part of the path to a wheel. I don't quite understand your (Paul's) point about the importance of sdists to open source (as opposed to a plain old tarball of the source, like what gitHub produces when you do a release.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Nathaniel is pushing a means of notifying "I can't build a sdist"<br>
that protects against backends accidentally not following the spec.<br>
</blockquote><div><br></div><div>"I can't do that" respond to any possible request makes sense. Unless "I can't build a sdist" violates the protocol -- which I don't think it should.</div><div> </div><div>> Should we trust the backend or not? Backends *will* have bugs - part</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
of "trust the backend" is simply telling the user that the problem<br>
behaviour they found is not pip's issue and should be reported to the<br>
backend. Is that a sufficiently bad user experience that we should try<br>
to improve it (experience with setuptools says that it is - why are we<br>
assuming that developers of new backends will be so much more<br>
conscientious and careful than the setuptools developers? *I*<br>
certainly don't feel that the setuptools developers are unusually bad<br>
- quite the opposite!)<br></blockquote><div><br></div><div>If that is a sufficiently bad user experience then the only other option is for "us" by some definition of "us" to build the back-end, too -- which is where this all started with setuptool. But my understanding is that goal is was not to force the whole stack to maintained together.<br></div><div><br></div><div>And really, the end-user will need to report the problem to the package maintainer, not the build tool maintainer jsu tlike they should no if something doesn't pip install.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Having a more robust means of saying "I can't build a sdist" than<br>
"return None" is protecting the user from issues with the backend. So<br>
is building via sdist.<br></blockquote><div><br></div><div>but only one particular set of issues -- when there are an infinite number of possible issues...</div><div><br></div><div>One other thought --</div><div><br></div><div>the easiest way to make an sdist it to simply copy the source tree.</div><div><br></div><div>So:</div><div><br></div><div>1) not a big deal to require back-ends to do it -- it's easy to do</div><div>but</div><div>2) back ends may do it the easy and sloppy way, and get build artifacts in the sdist, and then you are back where you started.</div><div><br></div><div>so requiring the sdist step in no way saves you from poorly written back-ends. It may make it worse, as you _think_ you are getting something clean.</div><div><br></div><div>-CHB</div><div> </div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>