On 05/15/2012 04:39 PM, Éric Araujo wrote:
Hi again,
Le 01/05/2012 14:28, Paul Moore a écrit :
On 1 May 2012 17:40, Chris McDonough<chr...@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?
- C
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
