[ckan-dev] ordering of plugins

David Read david.read at okfn.org
Tue May 31 18:17:56 UTC 2011


On 31 May 2011 18:34, Seb Bacon <seb.bacon at gmail.com> wrote:
> Great stuff.
>
> I think the whole extension system could do with a bit more discussion
> some time soon.  I think it's a great start but can think of various
> improvements.  For example (and this may be controversial), it would
> be nice for the configuration to live in the database, so a site
> administrator can edit it.

I assume the reason you've suggested this is that although a web
interface could edit the existing config file, it runs into the
problem of needing to restarting CKAN to reread the file and the
changes to take effect. But why not hack Pylons to reread the file? I
like the config file for editing on the command line.

Either way, the reread of the config will mean a fair bit of work to
rejig every use of the config in CKAN and extensions.

> The same place would have a concept of
> active and inactive modules so that there's a place to prompt admins
> to fill out stuff post-install, and we have the possibility of a nice
> failure mode.

Interesting - which extension did you encounter this gotcha? Either of
these solutions sound feasible, if this situation is going to come up
lots in the future.

David

> An alternative would be something like apache's module system.  Each
> extension has an ini file that it drops in a known location
> (extensions-available.d/).  Enabling them is a matter of editing their
> ini file and symlinking it to extensions-enabled.d/.
>
> This would make extension configuration management much easier.
>
> Seb
>
>
> On 31 May 2011 17:47, David Read <david.read at okfn.org> wrote:
>> Hi folks,
>>
>> David Raznick and I have been discussing CKAN plugins and worrying
>> about the order that they run in. I've done a bit of digging and have
>> added a section to the plugin docs - see below. In summary, the order
>> is the same for every run, and is determinable, although alphabetical
>> is not ideal and may need improving on in the future.
>>
>> David
>>
>> Ordering of extensions
>> ~~~~~~~~~~~~~~~~~~~~~~
>>
>> .. caution ::
>>
>>  The order that extensions are initially loaded is **different** to
>> the order that their plugins are run.
>>
>> The order that extensions are initially loaded is as follows:
>>
>> 1. System plugins (in setup.py under ``ckan.system_plugins``).
>>
>> 2. In order of the plugins specified in the config file: ``plugins =``.
>>
>> 3. If more than one module has a plug-in with the same name specified
>> in the config, then all those are loaded, in the order the modules
>> appear in ``sys.path``.
>>
>> The order that a plugins are run in, for example the order that
>> IRoutes extensions have their ``before_map`` method run, is
>> alphabetical by the plugin class.
>>
>> e.g. here is the order for these four extensions: ``<Plugin
>> DguInventoryPlugin>``, ``<Plugin FormApiPlugin>``, ``<Plugin
>> StatsPlugin>``, ``<Plugin WalesThemePlugin>``
>>
>> (This alphabetical ordering is done by
>> ``pyutilib.component.core:ExtensionPoint.extensions()``)
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>




More information about the ckan-dev mailing list