Thanks for the update! Glad this is still moving forward. I'll continue to prod the list if things stall again as I want to respond to "Python packaging is broken" with "actually your knowledge is just outdated, go read packaging.python.org". :) On Tue, 3 May 2016 at 11:28 Nathaniel Smith <njs@pobox.com> wrote:
On 3 May 2016 at 17:47, Donald Stufft <donald@stufft.io> wrote:
It will likely get decided as part of the build system PEP, whenever
On Tue, May 3, 2016 at 10:10 AM, Paul Moore <p.f.moore@gmail.com> wrote: 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig