On 5/16/12 9:40 AM, Paul Moore wrote:
On 16 May 2012 07:55, Tarek Ziadé<ta...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
