[Distutils] command hooks...

[Chris McDonough]

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?

- C