[Distutils] svn tagging setuptools command

[Ian Bicking]

Phillip J. Eby wrote:
> 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.

Indeed, this was my original plan; well, SQLObject had a sqlobject-admin 
script, and I was creating a paster script that would be more general 
and driven by entry points.

However, in an effort to Reduce The Total Number Of Things, I was 
thinking about moving these all into setup.py.  I would be okay with 
just one other script, not pushing everything into setup.py, but in 
practice I suspect that only I would use that one other script, and 
every project would have their own.

.onversely, 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).

Interesting, I'll have to try that out.  So I'm thinking I might be able 
to have someone add this to setup.cfg:

   [sqlobject]
   dbmodule = mypackage.db

And use that to kind of implicitly enable the SQLObject commands.  At 
least, assuming I can access arbitrary sections of the config from the 
setup (since sqlobject would imply several commands).  Or alterately in 
setup.py.  Hrm... maybe it has to be in setup.py, though, since 
setup.cfg is only used after the command is invoked, so it can't keep 
the command from being available?  Well, I suppose experimentation is in 
order.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org