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 <n...@pobox.com> wrote: > On Tue, May 3, 2016 at 10:10 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 3 May 2016 at 17:47, Donald Stufft <don...@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 > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
