Adding a facility for loading/saving a configuration file. This relies on
the new PyUtilib? plug-in architecture. By default, PyUtilib? supports the
use of the ConfigParser? package for reading/writing configuration info.
However, other plugins can be added to support other formats.
Unit tests are included, for which we have 100% coverage of this new code. :)
Setup skeleton of tests that will test the SimpleApplication?
mechanism. A goal of this is to more completely test the
logger_config and env_config modules, which support convenient options
for simple applications.
Basic registration of the EggLoader? has been tested, but not the core
functionality of this module.
The main changes in this commit relate to the import loader. This
capability now appears to work. Simple tests have been added to the
test suite, and I've verified the behavior of the loader (which
changed a bit).
Getting independent loading tests to work was a nightmare. I wound up
explicitly deleting the "pyutilib" package and reloading it in the
unittest code. Uugh! It's a miracle that the code coverage tool
Update to loading tests (which I apparently forgot in my previous commit).
Adding application-level tests.
Various fixes for SimpleApplication? and the
services that it relies on. In particular, reworked the setup of
logging. This sort-of works in a simple example: I can get logging to
work for the root namespace, but not for other namespaces.
Changing the naming convention for PluginEnvironment?. Now, a separate
namespace is not supported. John S. notes that this could cause problems
when we combine multiple applications. That's correct, but the old system
had problems when you automatically created namespaces based on the stack.
There's more to do here...
Updates to support the definition of a 'dummy' EggLoader? plugin.
This simplifies the application of this plugin, and the dummy plugin
doesn't provide a performance limitation. A logging message is generated
to warn a user that the plugin is not doing anything interesting.
Further reorg. I've consolidated all of the plugin stuff into the
pyutilib.plugin package, but I've segregated _all_ of the non-core elements into subpackages. I think that this meets the spirit of highlighting the true core of this package, without cluttering up PyUtilib? itself. Also, it
simplifies the imports that a user would need to use _just_ the PyUtilib? plugin
I've revised various test baselines. When things get imported in different
orders, that breaks the baselines. :(
Adding the import for the 'misc' subpackage. This adds makes
pyutilib.plugin dependent on other parts of pyutilib, but that makes
a lot more sense than having users explicitly import pyutilib.plugin.misc.
Reworked some tests so the class definitions only use
the declare_option() function.
It turns out that a user _can_ instantiate one of these classes.
I've put a ticket into Trac to see if we can restrict that ...
but at least for now it's convenient to _not_ have that restriction
when testing the option classes.
A variety of critical changes. These were driven by bugs exposed in the
Coopr tests, and they relate to basic functionality of the
current plugin framework.
. Renamed ExtensionPoint?.getitem to call. This provides for a more
natural syntax when asking for all of the extension points. With getitem,
you need to pass in None to get that information, but with call you just
. Added a hook for the ManagedSingletonPlugin?. After much though, I decided
not to make this part of core.py. That would have significantly extended
the requirements for this module (e.g. to include the core options code).
. Rework of the Plugin.new method. I simplified this to not explicitly
check if a PluginEnvironment? is a subclass. We're not using that
information, and this is not an expected derived class.
. Renamed Plugin.enable to Plugin._enable. This allows the ManagedPlugin? class to implicitly override this value and provide a
configurable value for _enable.
. Added the ManagedPlugin? and ManagedSingletonPlugin? classes. These classes
add a configuration option that can be used to enable/disable the plugin
within config files. Various plugins were reworked to derive from this
. Used super() in various constructor calls. This seems to work,
though there is much to be said about the pitfalls of multiple inheritance,
even using super(). For now, I'm not going to worry too much about whether
multiple inheritance works correctly for the plugins class hierarchy.
. Reworked default arguments for various methods, when mutable types are passed in. For example:
is a _dangerous_ declaration because if arg gets modified then it changes the
default value in subsequent calls to foo! I knew about this, but I was
reminded of this problem this week.
. Added the plugin_services module, which provides simplified
interfaces to various singleton plugin services.
NOTE: I'm starting to see problems in the test_plugin/app/load tests. The test_load2.py tests are
interferring with each other. I haven't figured out the root cause of this interference, but I think that
failure/success in one test impacts the state of subsequent tests.
Fixing a subtle bug exposed in Python 2.6. While
clearing the global plugin data, we need to be careful
to disable the PluginEnvironment? destructor, which normally
tries to deregister itself from the global plugin data.
The old code was removing data from a dictionary that had already