Idea

It would be useful to find or create a configuration system for use in repoze.bfg (and other frameworks) that had the same purpose as zope.configuration (aka ZCML), but rids itself of the hard dependency on zope.component.

Rationale

Most frameworks need some form of explicit configuration step. This usually happens in two phases. The first phase is to load the configuration data from some file(s). The second phase is an "execution" phase which operates against the configuration data. The execution phase is not passive, it's active. The return value of the execution phase is not terribly important, it is only executed in order to perform arbitrary setup.

It is often useful to "box this step in" to some known time period. Instead of relying on import ordering to do ad-hoc configuration, making the execution step explicit ensures that the configuration happens in a known order as a result of a single function call. It also forms a convention which can help load "the right" configuration for functional testing and other purposes.

The specific code that is executed depends on what the user puts in the configuration data. The configuration data is typically explicitly not Python: Python is often too powerful for this task. Instead, there is some controlled set of directives in a structured format that are available for users to inject into a configuration file.

Most frameworks also need somewhere to stash and retrieve application-specific settings (as opposed to module-scope settings), as more than one instance of an application using the framework may exist in the same process space.

zope.configuration provides such a system but it assumes that the framework developer is willing to "bite off" the entire Zope component architecture. Also, zope.configuration makes the assumption that there is a single global configuration; this is a limitation that makes it hard to run multiple instances of an application using the configuration system in the same process.

Requirements

• The pattern for loading and executing directives from configuration is similar to the pattern exposed by the design of zope.configuration. E.g. there is a "load" phase which reads data from a config file, and an execute phase which executes the configuration; these can be invoked independently as necessary.
• The input format should be overrideable (e.g. YAML vs. XML)
• No automatic dependency on zope.component (ie. the configuration registry itself is not a component architecture registry). It should be possible to use a zope.component registry within the system, but the configuration system should not assume it is populating a component architecture registry.
• The configuration system should allow developers to extend the system with new directives; for example, someone should be able to plug in an implementation of a directive that, when spelled in the config file by a user, could cause a set of Routes .connect statements to be run, or a ZCA utility to be registered.
• The configuration system should be able to raise an error when an unknown directive is specified or the options to a particular directive are somehow wrong.
• Configuration should be able to span multiple files. There should be a way to include configuration from another Python package or filesystem location.
• The configuration system should provide an application-specific data structure to both retrieve and temporarily store data at runtime.

Anyway, that's enough for now. Just thinking out loud.