[Distutils] Further extending of setup.py

[Ian Bicking]

Phillip -- any thoughts on this?  If this went in, this would allow me 
to start splitting up and simplifying some commands, as outlined in: 
http://blog.ianbicking.org/paster-and-scripts.html

Ian Bicking wrote:
> I'd like to get rid of the "paster" script, moving some of what it does 
> into setup.py or elsewhere.
> 
> To a degree that is possible, but I think requires some additions to 
> setuptools:
> 
> * An entry point group that is not globally looked up, like 
> distutils.commands.  This would be a set of commands the package 
> provides only for itself.  I expect it to look like:
> 
>    [distutils.commands.local]
>    sql_record = sqlobject.manage.distextension:sql_record
> 
> Exactly like what we have currently, just not looked up globally.
> 
> * Additionally, or probably even better, something that enumerates 
> locations for commands.  E.g.:
> 
>    extra_commands=['SQLObject']
> 
> And then it would look in the SQLObject egg for 
> distutils.commands.local, and apply everything found there to this 
> package.  Right now, for instance, buildutils adds a "pytest" command to 
> every project, even though it only applies to some projects (for some 
> commands this is ok, like "info", so two different entry points makes 
> sense).  A project could list itself to provide its own custom commands; 
> I think that won't be too circular.  Typically commands you provide for 
> yourself or someone else are different -- e.g., the SQLObject commands 
> don't apply to SQLObject itself.
> 
> * Everything that can be done on a deployed egg will probably go in 
> app/egg-specific command-line scripts, and maybe I'll make a little 
> framework to make these easier to write, but that's entirely an 
> implementation detail.  But I'm also thinking that extra_commands could 
> be used as a hint to that framework, and would kind of facilitate 
> coordination of in-development commands with after-deployment commands.