[Distutils] command hooks...

[Tarek Ziadé]

On 5/16/12 3:58 AM, Chris McDonough wrote:
> 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<chrism at 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

Cheers
Tarek


>
> - C
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig