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

[Toby Dacre]

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.

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/20130417/2e808d20/attachment-0001.html>