[Distutils] command hooks...

[Alex Clark]

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. 
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 at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-- 
Alex Clark · http://pythonpackages.com