[ckan-dev] pylons.app_globals vs pylons.config

Toby Dacre toby.okfn at gmail.com
Mon Apr 29 10:52:57 UTC 2013


On 17 April 2013 08:53, Toby Dacre <toby.okfn at gmail.com> wrote:

>
>
> On 16 April 2013 18:08, Sean Hammond <sean.hammond at okfn.org> wrote:
>
>> Hey, something I think we need to nail down (and document in our dev
>> docs) is whether CKAN uses pylons.app_globals (also known as pylons.g)
>> or pylons.config for configuration settings. We should pick one and
>> stick to it.
>>
>> The discussion started here:
>>
>> https://github.com/okfn/ckan/pull/693#issuecomment-16233559
>>
>> and I'm now moving it to the dev list.
>>
>> What I want to achieve is having all our config options along with their
>> associated metadata (docstrings, default values, types) defined in one
>> place, and be able to use autodoc to pull the docstrings into sphinx.
>>
>>
> We also want our config to be changed via the frontend ie optionally have
> values kept in the db.  We do this in app_globals.
>
> The docstring idea is good - or at least having the documentation with the
> defaults/type etc
>
>
> I think Toby is interested in abstracting CKAN away from Pylons so that
>> we can move to another web framework one day.
>>
>> Toby doesn't like pylons.config because you need to do asbool() and the
>> like and because it's not accessible from templates.
>>
>>
> `g` is used extensively in the templates as config was removed on purpose.
>
> The main reason I don't like config is that it is raw data ie false no etc
> and has no defaults
>
>  I'm not sure whether pylons.app_globals is the solution to this however,
>> if our aim is to abstract CKAN away from Pylons so that we can
>> eventually move to another web framework, then I'm not sure that moving
>> the config handling from one Pylons thing to another Pylons thing
>> really helps with that. But maybe it does?
>>
>> Maybe we need to define our own CKAN class or module for handling the
>> config settings, that will for now be implemented as a wrapper around
>> pylons.config but could in the future wrap something else without
>> changing its own interface. Currently we seem to have sort of done that
>> as a wrapper around app_globals but that seems a bit odd to me.
>>
>> _Globals which we use as app_globals is pretty much stand-alone from
> pylons
>
> Personally I think it would be good to look at this in 2.1 or 2.2 but
> stick with app_globals/g till we have a fully formed plan as that will make
> conversion easier whatever we eventually decide.
>
>
 More generally we have some requirements for the config options

1) avoid duplication of code
2) document each option where it is defined
3) Automatically generate the ckan html config docs
4) have default values defined (only once)
5) have a type (int, bool etc) so we don't have to keep re-parsing it
6) be available to templates
7) extensions to be able to add there own options and get any features eg
parsing
8) do some validation of options at ckan start-up - including that it has
documentation.
9) easy ways to deprecate/rename options
10) be able to override the file config from the database (allow editable
options)
11) be able to easily add the config options to docs using the `Adriá Hack`
https://github.com/okfn/ckan/commit/01cd2def9e2be7ffd0afb6de8c96c654b7572a7c(or
similar)
12) define all the core options in one place
13) sort the config vs globals issue for consistency
14) be documented
15)  deployment.ini_tmpl be kept in sync (maybe via some tests)


At the moment this is a bit adhoc and it would be good to get it cleaned up
a bit.

I'm happy to look at this.  There are some general issue like

Do we define the config options in python ie like currently in
lib.app_globals or in some other format I prefer the python as it's just
easier but others may feel different

Can people see if they are aware of any other requirements around the
config options


Toby
>
> _______________________________________________
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130429/17f6734f/attachment-0001.html>


More information about the ckan-dev mailing list