On 5/16/12 9:40 AM, Paul Moore wrote:
On 16 May 2012 07:55, Tarek Ziadétarek@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.