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