[ckan-dev] ordering of plugins

[Seb Bacon]

On 31 May 2011 19:25, James Gardner <james at 3aims.com> wrote:
> Hi Seb,
>
>> 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.
>
> Why is config in a database a pre-requisite? I'm very strongly against it
> having tried it before. Having said that I would like an API that makes it
> easier to set/add/delete config options in the config file which would
> provide the same benefit in that it means changes could be made through a
> web UI/command line. (I'm thinking postconf -e here).

I wouldn't call it a prerequisite.  But there is an argument that if
you want to copy a working site elsewhere, you should be able to move
all its non-sysadmin-state across with the database.

One argument against storing user-edited config on the filesystem is
that it introduces a potential security risk as you then require the
sysadmin to be careful with their write permissions.

When the config is in the database we can control that aspect directly.

>
>> 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/.
>
> I'm strongly in favour of this but there are lots of parts of the code that
> rely on the Pylons format though which would need replacing so it isn't a
> trivial request.

I've not looked at the code, so don't know what it would involve, but
had assumed it would be something as simple as a new ini-file
directive to include the contents of a folder?

> Maybe something for the future?

Sure, it's not urgent.  However as the number of extensions fast
increases, I do think it will become more important.  We're ending up
with larger and larger config files that become harder to organise and
navigate.

Seb