Phillip J. Eby wrote: > 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.
OK. >>> 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. Putting things in setup.py means that those things are pretty opaque for tools. For instance, when generating packages setup.py is a point of contention when you are creating a package that uses more than one framework. If the generator was able to handle the specific files like entry_points.txt with knowledge of what those files meant, most contention could be avoided. requires.txt is another thing that could be usefully manipulated with tools; for instance, if you had a tool that did commits to two projects at once, and updated the second project to require on the after-commit version of the first project. So it's not the writer plugin that bothers me at all, though I haven't looked at the details of that. It's that Python source is opaque. Anyway, another thing occurred to me. In addition to providing plain egg files, I'd like to allow egg+entry_point name to be a possible specifier. It would be nice if we had a convention for how to specify both at once. I'm using spec#entry_point_name in Paste, which works fine for me. >> 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. Configuration...? I don't see where that fits in? Or, at least, I figured that configuration would be figured out by each subcommand, and they'd share command-line options for that by convention. I did forget --version, though, which should be implemented in the parent command. >> 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...? Well, to be more specific, here's what I'd like for SQLObject: * A setup.py command, like "setup.py sql-record". This would take the current database schema as defined by the source, and write that out somewhere into the project's source (kept in the source as a historical record of all possible schemas the app has had.) * The setup.py command has to figure out where to find SQLObject classes in the project, by some configuration. I'd rather that configuration not go in setup.cfg, because it is used later... * The SQLObject-using-application would get several subcommands: - create - drop - show-sql - status - upgrade * These commands would read some configuration from the original egg, to find the history of schemas, and to find the module that holds the current SQLObject classes. So, particularly in the second case, adding SQLObject to your application introduces a set of commands, and those commands can all run off the same configuration, which they also share with the setup.py command. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
