On 5/16/12 3:58 AM, Chris McDonough wrote:
Adding two more (packaging and distutils2) which are similarly semi-documented and which don't even solve the problems that the previous ones do would serve no purpose, and baking them into Python itself will mean they can't evolve in important ways.
Oh, I think I need to answer to this too since you said you wanted to help. Packaging is not intended to be similar to setuptools in its features.
For instance we won't provide console scripts or entry points. The first one because 'script' is the same feature (except there's an indirection and I said before we could mimic this) The second one because we should build this kind of feature outside the stdlib (this is not something most people use, according to the survey I did back a few years ago, it's mostly zope/plone/repoze land)
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
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 ?