[Distutils] PEP 517 again

[Chris Barker]

On Mon, Aug 28, 2017 at 12:20 PM, Paul Moore <p.f.moore at 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.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170828/b379f5be/attachment.html>