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

[Paul Moore]

On 3 May 2016 at 19:28, Nathaniel Smith <njs at pobox.com> wrote:
> 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 :-).

Not a problem - I'm glad my mail prompted some movement, but I
completely understand that other things can get in the way.

> 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

Even though I was one who wanted a properly defined sdist format, I'm
inclined to be OK with a "whatever works for now" approach, so I don't
see a problem with documenting and tidying up the current de facto
standard. If Donald comes up with a good proposal, that's great - but
if not, we can always revisit that side of things later.

> 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.

Cool. No objections from me.

> 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.
[...]
> [2] Or if someone else wants to raise their hand and volunteer I
> wouldn't object, obviously I am a bit swamped right now :-)

I don't want to volunteer to take this on completely, as I'll probably
not have the time either, but if I can help in any way (research,
proofreading, writing parts of the document) let me know.

Thanks for the update!

Paul