Welcome to Tool’s documentation!¶
Tool is a lightweight framework for building modular configurable applications. It is intended to:
- be as unobtrusive as possible. No conventions except for APIs. The modules are structured following their own logic;
- store configuration in ordinary Python structures, impose no limits on them and support YAML input out of the box;
- encourage modularity by providing a simple but flexible layered API for extensions with support for dependencies;
- stick to existing standards and APIs;
- combine existing components: Argh (argparse) for commands, PyDispatcher for signals;
- let user choose non-critical components but ship with batteries included: Werkzeug for request handling and routing (yes, even this is pluggable!), Jinja and Mako for templates, Doqu for modeling and more specialized extensions, repoze.who for authentication and so on;
- keep even some core functionality (such as routing and serving) as plugins so the framework can be used for CLI, web or CLI+web purposes without adding weight when it is not needed; moreover, the user can swap almost every component without breaking other components.
- Command-line interface
- Built-in commands
- Context locals
- Debugging utilities
- has a more complex and much more restrictive API than that of Tool. In fact, Tool also has a complex API for extensions but it is optional.
- is based on outdated optparse and therefore is bound to implement some features already present in argparse (e.g. nested commands and some help-related stuff).
- depends on ConfigObj and stores the settings in ugly ini files while Tool allows the configuration to be stored in any format (favouring the clean YAML) including simple Python structures.
- stores the environment is stored in a module-level variable while Tool stores it in extension objects within the application.
- has the notion of “namespaces” similar to Tool‘s “features”.