[ckan-dev] ordering of plugins

Seb Bacon seb.bacon at gmail.com
Wed Jun 1 07:34:24 UTC 2011


On 31 May 2011 19:17, David Read <david.read at okfn.org> wrote:
> 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.

I can't remember.  But the general point is that it's very easy to
overlook a particular bit of config for a particular extension, if the
only way of getting going is copy-and-paste from a README (as at
present).

A particular use case is migrating configuration between servers.  You
need to know which bits of which plugin may or may not need changing
when the host changes.  The fact that a plugin's configuration can
live anywhere within [app:main] makes it not-very-discoverable.

Seb




More information about the ckan-dev mailing list