[Distutils] Further extending of setup.py

Phillip J. Eby pje at telecommunity.com
Wed Apr 19 21:42:30 CEST 2006


At 12:47 PM 4/19/2006 -0500, Ian Bicking wrote:
>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']

You can pass a 'cmdclass' argument to setup() to accomplish these 
things.  Normally, it's expected to be a dictionary, but as long as you 
give it an object that implements 'in', 'get()', 'keys()' and 
setitem/getitem operations, you should be good to go.  (The distutils and 
setuptools both cache their own lookups by assigning items back into the 
cmdclass object.)

If you come up with a nice "command map" object that lets you do something 
like:

      setup(
          cmdclass = CommandMap(
              # configuration stuff here
          ),
          ...
      )

then it would make a nice addition to setuptools for people that need it.


> >A project could list itself to provide its own custom commands;
> > I think that won't be too circular.

That's only 'cause you haven't tried it yet.  Setuptools has to do this, 
sort of, and trust me, it's a bitch.  :)


> > Typically commands you provide for
> > yourself or someone else are different -- e.g., the SQLObject commands
> > don't apply to SQLObject itself.

That doesn't matter; the problem is that until your egg_info is generated, 
you don't have a pkg_resources.Distribution in existence to provide the 
entry points.


> > * 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.

I actually do want "nest" to provide a nice mini-framework for writing 
command-line apps as functions -- sort of a stripped-down cross between 
peak.running.commands and peak.running.options.  One key feature will be 
that the commands have to accept an argument that's a logger for them to 
use, and the verbosity of that logger will be managed by the 
caller/framework, not the function.  (Meaning that verbosity options will 
be handled by the framework when running via the command line.)

Although perhaps I should just write this hypothetical framework as a 
separate package...  but I want nest to be a part of the core setuptools 
distribution.  I guess if you're going to depend on the command line 
framework, you might as well depend on setuptools, since you'll need to 
have setuptools in order to be able to depend on the hypothetical command 
line package.  :)  (Confusing, isn't it?)




More information about the Distutils-SIG mailing list