[Distutils] moving things forward (was: wheel including files it shouldn't)

[Nathaniel Smith]

On Tue, May 3, 2016 at 10:10 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 3 May 2016 at 17:47, Donald Stufft <donald at stufft.io> wrote:
>> It will likely get decided as part of the build system PEP, whenever that
>> gets picked up again.
>
> Yes, but on 15th March
> (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
> Robert posted
>
>> Just to set expectations: this whole process seems stalled to me; I'm
>> going to context switch and focus on things that can move forward.
>> Someone please ping me when its relevant to put effort in again :).
>
> And I think that's right. The whole build system PEP issue appears
> stalled from a lack of someone willing (or with the time) to make a
> call on the approach we take.

No, no, Nick's not the blocker. I'm the blocker! (Sorry)

Donald + Robert + I had a longish conversation about this on IRC a
month ago [1]. I volunteered to summarize back to the mailing list,
and then I flaked -- so I guess this is that belated email :-).

Here's the tentative conclusions we came to:

Blocker 1 is figuring out what to do about the sdist format. The
debate is between keeping something that's basically the current
format, versus somehow cleaning it up (e.g. Donald's "source wheel"
ideas). To move forward:
- I'll write up a PEP that attempts to just document/standardize the
current de facto sdist format and send it to the mailing list
(basically: filename convention, PKG-INFO + a list of which fields in
PKG-INFO pypi actually cares about, presence of setup.py), and adds
some sort of optional-defaulting-to-1 SDist-Version (I guess in a file
called SDIST by analogy with WHEEL). And also contains a rationale
section explaining the trade-offs of standardizing this versus
creating a new extension.)
- Donald will make his case for the new extension approach on the mailing list
- We beg Nick to read over both things and make a ruling so we can move on

Blocker 2 is figuring out whether the new pip <-> build system "hook"
interface should be command-line based (like the current draft of PEP
516) or Python function call based (like the current draft of PEP
517). It sounds like currently Donald and I are in favor of the python
hooks approach, and Robert is indifferent between them and just wants
to move forward, so we agreed that unless anyone objects we'll drop
the command-line approach and go ahead with refining the Python
function call approach. So... if you want to object then speak up now.

Then there are a bunch of details to work out about what hooks to
provide exactly and what their semantics should be, but hopefully once
we've settled the two issues above that will be an easier discussion
to have.

So yeah, basically the next step is for me [2] to write up a spec for
how sdists currently (really) work.

-n

[1] Logs (split across two pages in the log viewer):
  http://chat-logs.dcpython.org/day/pypa-dev/2016-03-30#18.23.46.njs
  http://chat-logs.dcpython.org/day/pypa-dev/2016-03-31#00.29.32.lifeless
[2] Or if someone else wants to raise their hand and volunteer I
wouldn't object, obviously I am a bit swamped right now :-)

-- 
Nathaniel J. Smith -- https://vorpus.org