[Distutils] command hooks...

[Tarek Ziadé]

On 5/16/12 5:01 AM, Alex Clark wrote:
> Hi,
>
> On 5/15/12 9:58 PM, 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?
>
>
> +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. 

This will never happen because Distribute's goal was 1/ to allow us to 
fix some bugs in setuptools and 2/ set some bridges for "packaging" 
adoption. But the final goal is to let it die where it is.



> 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.)
packaging provides two things:
- reference implementations for the PEPs we've written - that can be 
used by any tool
- a replacement for distutils-the-tool, with improvements and backward 
compatible helpers, like a way to browse packages installed by other tools

The only reason we did  not do this in distutils was because any change 
I made in the code back then, even on private parts, was potentially 
breaking all the legacy code out there
>
>
> Alex
>
>
>>
>> - C
>> _______________________________________________
>> Distutils-SIG maillist - Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
>