[Distutils] command hooks...

Tarek Ziadé tarek at ziade.org
Wed May 16 09:49:08 CEST 2012

On 5/16/12 9:40 AM, Paul Moore wrote:
> On 16 May 2012 07:55, Tarek Ziadé<tarek at ziade.org>  wrote:
>> I'd suggest you list what you can't do with "packaging" today and we work
>> through that list to point which features are missing and should be
>> developed *outside* the standard lib, and which ones are in "packaging" or
>> should be
> This would be a very good step - but rather than simply getting
> responses in the mailing list, can I suggest that we need some sort of
> central location where the features still outstanding for packaging
> can be tracked. Call it a roadmap if you like. Maybe it should be a
> PEP - simply because I can't think of a better place to put it, but
> I'm open to suggestions (I don't think the bug tracker is the right
> place, fwiw).
A wiki page sounds good, as long as each point turns into a bug at some 

> At the moment, the biggest issue I see is that there are lots of
> discussions about what people believe is missing, but nothing clearly
> documenting what's intended to be there (and what is not - for
> example, your comment about entry points).
> As a starter, my key "missing requirement" is support for binary
> distributions - whether this is a new "universal" format, or whether
> it is reusing the bdist_wininst/bdist_msi formats, I don't really
> care, but it needs to be formalised with a migration path, backward
> compatibility support considered, etc.

Do you feel like you could start the windows story section on that wiki 
page ?

>> IOW: packaging should only be the common basis and provide a basic installer
>> - not a full fledge tool you can use to replace the most advanced setuptools
>> features. And we want it pluggable enough so people can build pluggable
>> features on the top of it, like Eric explained earlier
>> Does that make sense ?
> I would assume as a first guess that it should replace all of
> distutils, though? Ideally there should be no reason for people to use
> distutils for anything once packaging is available - am I right?
It does replace all distutils since it's a fork of it.

The parts that is missing on purpose is bdist_rpm because we want 
anything RPM-related to
be dealt outside the stdlib : there's a whole gap between how 
rhel/fedora guys do their packaging
and what we offer with bdist_rpm, which seems to be perfect for... red 
hat 4 ?

FWIW I have started the pypi2rpm project to group tools for RPM-izing 
python projects.

Windows binaries were kept because it seems easy and feasible to 
maintain those from the stdlib --
but they still smell like old stuff because we don't have a Mr Windows 
in the distutils project.

It was mostly Martin doing the legit work to make it work, and a couple 
of other people (forgive
me if I forget someone)

So... the windows binary story will improve if we get a champion for this.


More information about the Distutils-SIG mailing list