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 routine.
-
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 non-setuptools packages).
-
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
py.test
support. But, for instance,
flakes
(the
pyflakes
runner) would be global available (but still locally
configurable).
-
setup.cfg
contains project-specific development-task configuration.
-
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.