[IPython-dev] Configuration, hooks and plugins
Tue Jun 30 17:38:19 CDT 2009
On 2009-06-30 16:42, Brian Granger wrote:
> One of the things I am going to do in refactoring the IPython core
> this summer is to consolidate the current configuration and hooks
> As I see it, here is our current situation. We have 3 different
> configuration systems:
> 1. The basic config stuff in ipythonrc. This uses key/value pairs in the form:
> key value
> 2. The more dynamic stuff in ipy_user_conf.py
> This allows the user to dynamically configure ipython after it is
> running by calling ipapi, loading extensions and setting hooks.
> 3. IPython.kernel uses .ini files for configuring the parallel computing stuff.
> This we current have: 3 config systems and hooks. I propose that we
> move to 1 config system and a proper plugin system (maybe just a
> different name for a hook).
> Config System
> By a "config system" I mean key, value pairs that determine how
> IPython classes are created and behave. But, it is a bit more
> complicated than this. First, some types of keys/values should be
> changed only when IPython is starting up, other types of keys can be
> changed at any time while IPython is running (such as the traceback
> type, color mode, etc). Also, some types of key/values can be set at
> the command line as well. Thus, here are some characteristics that
> our config system needs to have:
> * KISS. A pure python config system that can be implemented in a few
> hours, not weeks or months. If we use an external dependency it must
> be trivial to package and pure python (no traits!)
> * An IPython module/class/function needs to be able to say "here is a
> configuration key, here is it's default value, it will appear is this
> config file, here is how it should show up at the command line, it
> should/shouldn't be changed dynamically"
> * When objects are created, they need to be able to get the current
> global value of the configuration key. This raises the question of
> how configuration information gets to IPython objects.
> * We need a way of handling things that can be set at startup, but
> that can also be changed at runtime (often through magics). We might
> way to keep these things separate though. We could say that "config"
> means things that are set when an object is created and can't be
> changed from then on. To handle things that can be changed at
> runtime, we could have a completely different api that ties into the
> magic system.
> Currently we use "hooks" to allow people to customize how IPython
> behaves in non-trivial ways. Typically, hooks involve implementing
> some complex behavior by in a python function. The current hooks
> system is quite messy and grew into existence partly because IPython
> simply didn't use good object oriented design. I propose that we move
> to a plugin system, where a plugin is a python class that adheres to a
> very narrow and API and implements a single behavior. We should have
> a very simple API for registering plugins at startup and runtime, and
> we probably want to create a .ipython/plugins directory where users
> can put plugins. Many of the things in Extensions will probably end
> up as plugins. I have fewer thoughts on how to implement plugins, but
> I know that we won't be able to use any of the fancy ways of doing
> plugins like zope or setuptools.
I like Mercurial's approach. Plugins are just Python packages/modules exposing a
particular API. Having those packages installed *does not* enable them. To
enable them, you list the ones you want in the configuration file. Truth be
told, that's fairly similar to the current situation: you just import the
appropriate things in your ipy_user_conf.py and maybe activate them, except that
there is no standardized plugin API.
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the IPython-dev