On 5/16/12 3:58 AM, Chris McDonough wrote:
On 05/15/2012 04:39 PM, Éric Araujo wrote:
Le 01/05/2012 14:28, Paul Moore a écrit :
On 1 May 2012 17:40, Chris McDonoughchrism@plope.com wrote:
Is there a PEP for the "packaging" package? Is there any sort of unfinished business I can help with?
AFAIK, there's no specific PEP for packaging (there are a number of related PEPs, but nothing specific like a roadmap).
Yep. distutils2/packaging implement PEP 345 (Metadata 1.2), 376 (dist-info directory a.k.a. installation database) and 386 (version numbers), and also the older Metadata PEPs like distutils, but there was no PEP to discuss inclusion of d2 in Python 3.3: it just happened when a core developer (Martin von Löwis) indicated he was opposed to work on features (to add support for PEP 384 — Stable ABI for example) outside of the Python repository. I think that no PEP was asked by anyone because distutils2 is forked from code already in the stdlib and it implements accepted PEPs. There are small and big features added or in progress, many of them inspired by setuptools, that don’t have a PEP though.
As I said on my other reply there is no friendly list of issues or roadmap, only unsorted bugs and what’s in my mind.
OK. Is there a way for me to take a look at the unsorted bugs?
I'm sure Éric can give you much better pointers on what would be useful, but one issue I've tried to raise a few times, and more recently Jim Fulton raised here (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html) is that of binary distribution support in packaging2. I've never had the time to shepherd a proposal through beyond the "initial debate" stage, and I know it's not getting high on Éric's list of priorities, but it would be good to see some movement on this.
Indeed, in private email with Paul I agreed on the importance of a binary distribution format and did a pre-publication review of his PEP, but we did not finish our discussion nor incorporated the alternate proposal that was discussed at PyCon and on the mailing list (which makes it hard to see a clear picture — PEPs are good :)
It seems unlikely that this hard topic can be solved for Python 3.3 / distutils2 1.0; what can be done however is to make sure that the extensibility hooks in d2 are well tested and documented so that when a bdist PEP reaches agreement and is implemented, a simple pysetup call and two lines of config will be all it takes to be able to use the new command.
I know that the situation is far from ideal, and far from our goals for 3.3, but anyway d2 was never intended as a full replacement for setuptools and pip (more on that in an upcoming reply to another of your messages when you listed the setuptools features used by Pyramid). I think packaging in Python 3.3 will be a first version put in the stdlib to gather feedback and reports, not a finished stable product.
I really don't want to add stop energy here, and I'm more than willing to row to get something going, but I'm afraid if that's the diagnosis, it means I'll personally have to oppose the inclusion of packaging in 3.3. We currently already have at least 3 competing solutions (setuptools, distribute, and distutils itself), and people are baffled about which to use and how to use it. Adding two more (packaging and distutils2) which are similarly semi-documented and which don't even solve the problems that the previous ones do would serve no purpose, and baking them into Python itself will mean they can't evolve in important ways. I'd suggest we just put the brakes on and slate something better for 3.4. Does that make sense, or does that make people sad?
I know the idea of having packaging in the stdlib is something some people disliked, from day 1. And if I recall correctly, you did not like this either back then.
I am -1 on for two reasons:
1/ your argument about people being baffled about which tool to use will be worse if we work outside the stdlib. Having packaging in the stdlib and distutils frozen here, leads the path: "hey, the next tool in the stdlib is packaging"
2/ packaging is completely mature for some parts, like the PEP 386 implementation. And having the packaging.version module in the stdlib is a great step forward for standardization The pep 376 implementation is also providing great APIs to push all tools to inter-operate.
If we develop this tool outside, I am afraid we will just add more confusion in the mix.
Can you see packaging as a set of utility at this point, rather than a tool that's going to replace instantly all the legacy tools ?
I am adding Guido in cc for his opinion on this
Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig