[Distutils] svn tagging setuptools command

[Ian Bicking]

Ian Bicking wrote:
> So, I made my first setuptools command; I don't know where it really 
> belongs, but I've dumped it here for now: 
> http://svn.pythonpaste.org/Paste/Deploy/trunk/paste/deploy/tag.py

I had kind of forgotten about buildutils 
(http://buildutils.lesscode.org/) -- maybe this should go there?

Looking through buildtools, there's also some overlap with some of the 
other things I'm thinking about in terms of providing management 
frontends to applications.  I've started just a small portion of this in 
PasteScript: http://svn.pythonpaste.org/Paste/Script/trunk/

But I've been debating how the system should work; setuptools/distutils 
commands are extended globally, which sometimes is perfect.  But other 
times I want them local to a project.  For instance, I want a command to 
create a servlet -- but only in my WebKit/Wareweb projects, of course. 
buildtools pytest command is nice, but only if I'm using py.test -- if 
I'm not using py.test there's not much point.  In contrast, buildtools 
stats and flakes commands are applicable to any project.

In PasteScript I've been setting up a system where plugins are 
specifically enabled (this is actually about all I've really written 
yet).  paste.script.command 
(http://svn.pythonpaste.org/Paste/Script/trunk/paste/script/command.py) 
basically looks for a special file in the egg-info dir 
(paster_plugins.txt) and loads those plugins (extra commands as entry 
points, recursively checking for extra plugins), as well as any plugins 
on the command-line.  A command I have not yet written would allow you 
to add plugins (without editing that file), so you might add a plugin 
for your web framework (e.g., that create servlet command), your 
persistence framework (e.g., SQLObject has tools for doing management on 
databases), your development environment (e.g., the svn tag tool), your 
documentation framework (pudge, epydoc, etc), and so on.  Most of these 
are orthogonal to each other.

I don't know if setup.py is the right frontend for all of these.  One 
specific issue is that one command creates the basic framework of a 
package, including a setup.py file.  But maybe setuptools could be 
extended to support two kinds of entry points: one that is applied 
globally (what it currently has), and one that is applied only on demand 
(for framework-specific commands).

One option for the creation of an initial framework would be something 
like "python -m buildtools.createpackage" or something; it's not a 
command you need that often.

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