[ckan-dev] CKAN config - definitions

[Toby Dacre]

Hi,

Following on from the discussion about the ckan configuration:

We need to define config options currently we do this in app_globals

eg

'search.facets.default': {'default': '10', 'type': 'int',
                             'name': 'facets_default_number'},

This needs to be expanded for example to have a description, example etc
This starts to get messy and hard to read.

I want to add a new file like this

config_options.ini
============

[search.facets.default]
default = 10
type = int
name = facets_default_number
description =
This is some long bit of rst
so that it can be in the docs


..note::

  something important

example = config_options.ini = 10

[next.option]
....

Would this be an acceptable format for people?  This would be the only
place that the config options where defined.

Toby

previous discussion below for reference

On 30 April 2013 16:05, Adrià Mercader <adria.mercader at okfn.org> wrote:
> I'm a big +1 on strict namespacing at least at 2 levels:
>
> ckan.search.{...}
> ckan.auth.{...}
>
> Also having the same convention for extensions:
> ckanext.spatial.{...}
> ckanext.pdeu.{...}
>
>
> The tests sound also good
>
>
> Adrià
>
>
> On 30 April 2013 13:55, Sean Hammond <sean.hammond at okfn.org> wrote:
>>> > > 8) do some validation of options at ckan start-up - including that it has
>>> > > documentation.
>>> >
>>> > Yeah this would really help a lot.
>>> >
>>> > But even if we implement a CKAN options system in app_globals of
>>> > wherever that has this sort of validation, how can we prevent code
>>> > from just accessing some undocumented option via pylons.config directly?
>>> > If we really want it to work we might have to monkey-patch something
>>> >
>>> >
>>> One way might be to remove undeclared options from the config but that
>>> might break many plugins so probably a bit mean.  We can write a test to
>>> look for `bad` code in core trying to import things from pylons rather than
>>> through lib.common that would be quite simple and effective.
>>>
>>> Due to the plugins issue we will have to move plugins over first.  I think
>>> that we could do this either by a plugins.toolkit function or just adding
>>> an extra method to the IConfigurable Interface.  Of course we need to sort
>>> core first.
>>
>> Tests sound like a good option, least invasive.
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev



-- 
Toby Dacre

The Open Knowledge Foundation

Empowering through Open Knowledge
http://okfn.org/  |  @okfn