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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
