I think the biggest thing missing wrt to command hooks is the ability
to have the tool automatically generate a OS specific wrapper (.exe for
windows, extension less with a shebang for *NIX). While I think it would
be useful for this feature to live in std lib, I don't think it's near as required
as getting the core of packaging into stdlib.

Attempting to create packaging as outside of stdlib brings up images
of http://xkcd.com/927/, and to me the only thing prevent packaging
from just being another standard is the "Blessing" that comes with
being in stdlib.

On Wednesday, May 16, 2012 at 2:55 AM, Tarek Ziadé wrote:

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 ?


Distutils-SIG maillist - Distutils-SIG@python.org