paster and scripts
I've been thinking about paster (the PasteScript frontend) and setuptools and
whatnot, and thinking about how to simplify them.
Here's my current thinking (note "application" = "web application";
this stuff doesn't entirely apply to other models of applications):
- Each "application" will usually get a script. This script manages
instances of the application.
- Some little framework for this script creation is created, probably
similar to PasteScript. But it's optional to use this; it's just
that using such a framework you can get near-instant access to
commands inherited from other frameworks, like a database-setup
- Inherited commands that require configuration will typically look in
.egg-info/ for configuration files. These configure the
project/application in relation to the frameworks that it uses.
Not to be confused with configuring application instances.
- "Development" tasks go into setup.py extensions. These are
opt-in new commands that refer to the development process, not to
application instances. For instance, python setup.py
make-servlet. (This requires an addition to setuptools)
- The Buildutils pbu script
gets slightly nicer, so you can do pbu make-servlet and it will
find the nearest parent setup.py and call it, and add on
Setuptools features implicitly (so pbu develop will work for
- Probably a number of features of Buildutils will be moved elsewhere,
like the pudge command into the Pudge package.
- Some of those features will also be opt-in (but not all), like
But, for instance, flakes (the pyflakes runner) would be global
available (but still locally configurable).
- setup.cfg contains project-specific development-task
- A new command -- maybe nest or paster create refactored or
something -- is for bootstrapping new projects. A project that
doesn't yet exist has no setup.py of course, and no script, so
those options don't apply here.
I'm not sure where the current paster make-config/setup-app goes.
setup-app (which takes a configuration file and does any system
setup -- like creating a database) can be a specific command in the
app-specific script, of course. But there's no enforced uniformity
then, and you can't be sure how any particular application is setup.
And make-config actually implies installation of a package, in
addition to the uniform way of creating a blank(ish) configuration
file. Maybe these will become commands in a new paste-deploy
script of some sort.
Anyway, my thoughts at the moment.
Created 06 Apr '06