[Distutils] Further extending of setup.py

[Phillip J. Eby]

At 03:14 PM 4/19/2006 -0500, Ian Bicking wrote:
>It looks like, if I do this, it will also have to implement the current 
>default behavior of finding distutils.commands providers.

No it won't.  You should just look up things that you want to provide; 
setuptools and distutils will do their own thing if your __contains__ says 
False or your get() returns the default when they ask for a command 
class.  They will then call your __setitem__ to cache whatever they find.


>>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.
>
>OK, I'll look into that.  I'm guessing it'll be something like 
>CommandMap([eggs]), and maybe some other options, though I can't think of 
>any at the moment.  Maybe also reading .egg-info/command_map.txt if not 
>given any list of eggs -- I'd like to keep options for putting metadata 
>into .egg-info/*.txt files instead of setup.py.

Yecch.  When I first started doing egg stuff for setuptools, I thought it'd 
be nice to just edit files in .egg-info, and then I quickly got sick of 
it.  IMO, setup.py should be a one-stop-shop.  It's easier to explain to 
setup authors, too.  I can understand not wanting to go to the trouble of 
implementing an egg_info "writer" plugin, but trying to show people how to 
actually use these things, I think your users are a lot better off if all 
they have to do is  pass in a setup keyword or two.


>I think the features for a simple two-level command framework would be 
>fairly simple:
>
>* Register commands somehow (entry points, I suppose).  Commands have a 
>name and aliases.
>* Commands can be called to run them, with all arguments after the command 
>name.
>* Commands have a help() method or something like that, that returns a 
>string help message.  Probably two forms -- a long-form help, and 
>short-form.  Maybe only the short form?
>* The framework provides "cmd -h", "cmd help", "cmd -h subcommand", and 
>"cmd help subcommand".  The last two might just call "cmd subcommand -h" 
>internally.
>* I suppose the framework needs to be given some global help message.
>* It should be possible to hide commands or aliases from help.  E.g., 
>commands that represent an internal interface, or aliases that are only 
>provided for backward compatibility.
>* Maybe a standard way to activate specific eggs, e.g., "cmd 
>--require='Foo==1.0' ...".  Maybe also a way of controlling the 
>PYTHONPATH, since setting environmental variables is not equally easy in 
>all environments.
>
>Everything else should be possible to build from there with other 
>sub-frameworks.

You left out configuration.


>Self-referencing entry point loading would be nice.  Then, for instance, 
>you could do:
>
>   entry_points="""
>   [whatever.this.group.is]
>   sql-setup = sqlobject.commands:setup_command
>   """
>
>If setup_command is called with the package's Distribution object, then it 
>can read config files or whatever from the egg, and you don't have to 
>create little bits of glue all over the place.
>
>Hmm... putting information into the entry point name is problematic here, 
>because SQLObject would give a set of commands which would be a bit 
>tedious to enumerate, and it would be better if you could introduce the 
>whole set of commands with one entry point.  Also, it doesn't resolve the 
>problem of aliases.  Though it does give you an opportunity to resolve 
>naming conflicts by renaming a command.

Sorry, I don't really understand what you're trying to do here.  Are you 
talking about adding something to "nest", or...?


>Would setuptools stop using the distutils command framework?

No - it's necessary for compatibility, and to handle the intricate 
interdependencies where some commands depend on values computed by other 
commands.  Nest has much simpler needs that would be better served by less 
implicit coupling.