Hi, On 5/15/12 9:58 PM, Chris McDonough wrote:
On 05/15/2012 04:39 PM, Éric Araujo wrote:
Hi again,
On 1 May 2012 17:40, Chris McDonough
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
Le 01/05/2012 14:28, Paul Moore a écrit : 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?
+1. I think that makes sense. I'd be willing to work on something if I felt like I understood what was going on, which I don't. For example, distribute's goal seems very clear: provide a well-maintained and frequently-released setuptools. It would make sense (to me) to include distribute in a future release of Python, to close the loop of the non-std-lib-packaging-lib-built-on-top-distutils-but-never-included-in-the-stdlib-situation. But IIUC, it's too convoluted to attempt such a thing, and distutils2/packaging was meant to provide us the freedom to break backwards compat, but to what end? I don't think I fully understand the over-arching, real-world practical goals are for packaging in Python 3.x (other than to provide the pysetup command, and ini-style configuration over setup.py.) Alex
- C _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Alex Clark · http://pythonpackages.com