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.