[Distutils] Further extending of setup.py
ianb at colorstudy.com
Wed Apr 19 19:47:23 CEST 2006
Phillip -- any thoughts on this? If this went in, this would allow me
to start splitting up and simplifying some commands, as outlined in:
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
> * 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:
> 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.
More information about the Distutils-SIG