[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
point
> 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.
Cheers
Tarek
More information about the Distutils-SIG
mailing list