[Distutils] svn tagging setuptools command

[Phillip J. Eby]

At 10:04 PM 8/29/2005 -0500, Ian Bicking wrote:
>My vision of how it would work with command-packages would be like:
>
>    python setup.py plugins --list
>    # get a list of installed and uninstalled plugins, using entry points
>    # to discover commands
>    python setup.py plugins --remove=EggName
>    python setup.py plugins --add=EggName
>    # these change setup.cfg
>
>I'm not sure whether you'd specify eggs, eggs+entry points, modules, or
>what.  Or any of the above.  I still have to remind myself how the
>underlying stuff works.

I'm not clear on what you're trying to do exactly.  However, keep in mind 
that distutils commands running from setup.py aren't the only way to skin 
this cat.  You can always define entry points in a different group than 
'distutils.commands'.

For example, when I create the 'nest' script, I'll probably have a 
'nest.commands' entry point group that will be searched for commands.  Such 
"non-setup" scripts can always use setuptools.sandbox to run a setup script 
and thus get access to setup metadata if they need to.  So, if you need 
some kind of "dbadmin" tool for SQLObject, you can always have it use its 
own command entry points stuff, and then invoke setup.py with e.g. the 
--command-packages option.

Conversely, if you want to enable certain setup.py commands based on the 
availability of specific setup() metadata, there's already a facility for 
that.  Register an argument validator in 'distutils.setup_keywords', and if 
the metadata you want is present, it will be called.  Your hook can then do:

     dist.cmdclass.setdefault('cmdname',command_class)

to register the additional command(s).  Argument hooks are called while the 
distribution object is being created, so this will be before the distutils 
has done anything with the commands.

Note that you can't use this technique to *remove* commands that already 
exist in the distutils or setuptools, only to optionally-add them.

Anyway, for commands that depend on non-standard setup metadata, this is an 
ideal way to hook them in, since you'll need a distutils.setup_keywords 
entry point to do argument validation anyway.  So if the custom metadata 
passes validation, just register the additional command class(es).

Thus, if you have setup() arguments for say, a DB schema, then you could 
automatically enable dbcreate/dbdrop commands for the setup script in that 
case.  If the script doesn't supply the keywords for schema information, 
your keyword entry point won't get imported, and so the commands won't get 
added to the list for the setup script.