On Mon, Aug 28, 2017 at 12:20 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> > interface). So if pip calls build_sdist and then build_wheel, there will > be > > two source distributions built (one by pip and one by setuptools) before > > building a wheel. 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. > This is precisely the question - whose responsibility is it to ensure > that sdist->wheel vs build_wheel equivalence is maintained? The PEP > says it's the backend's responsibility, so pip shouldn't need to do > anything. > makes sense to me. But, we're currently having debates about "return None" which hinge on > "if backends have bugs, return None might not work well". Sure - but > if backends have bugs, they may not maintain wheel equivalence. 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. The only thing we really need to distinguish is " that functionality is not implemented" from "something went wrong" 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. > To that extent, I'm with Donald - pip going > sdist->wheel protects the user against the known-to-be-an-issue bug > that the backend doesn't ensure wheel equivalence. pip can not protect the user from a poorly written back-end. And it shouldn't try. * Chris Barker has pointed out that backends have no reason to support > sdists now. > 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. * Nathaniel is pushing a means of notifying "I can't build a sdist" > that protects against backends accidentally not following the spec. > "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. > Should we trust the backend or not? Backends *will* have bugs - part > of "trust the backend" is simply telling the user that the problem > behaviour they found is not pip's issue and should be reported to the > backend. Is that a sufficiently bad user experience that we should try > to improve it (experience with setuptools says that it is - why are we > assuming that developers of new backends will be so much more > conscientious and careful than the setuptools developers? *I* > certainly don't feel that the setuptools developers are unusually bad > - quite the opposite!) > 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. 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. Having a more robust means of saying "I can't build a sdist" than > "return None" is protecting the user from issues with the backend. So > is building via sdist. > but only one particular set of issues -- when there are an infinite number of possible issues... One other thought -- the easiest way to make an sdist it to simply copy the source tree. So: 1) not a big deal to require back-ends to do it -- it's easy to do but 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. 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. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
