On 16 May 2012 07:55, Tarek Ziadé email@example.com 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).
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.
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?