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

Mon Apr 29 16:13:19 UTC 2013

On 29 April 2013 16:50, Sean Hammond <sean.hammond at okfn.org> wrote:

> >  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
>
> We should have a naming scheme for config options. What characters are
> allowed in config option names? Config options should be named so that
> options related to the same feature share a substring and therefore sort
> next to eachother alphanumerically.
>
> For some configs this is already done, others not.  For example, we
> have:
>
> ckan.cache_enabled
> ckan.static_max_age
> ckan.cache_expires
>
> which are apparently the same feature (or not?), should be something
> like:
>
> ckan.cache.enabled
> ckan.cache.max_age
> ckan.cache.expires
>
> This would probably mean renaming a lot of options.
>
> __________________
>

I think this is a good plan.  Part of the requirements is allowing renames

I see the process as allowing both names for a period of time and warning
users to update their config files to the newly named option.  I also
suspect that renames would allow for the `Adriá Hack` to be implemented
more easily.  And as you've mentioned previously group config options
alphabetically

_____________________________
> 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/fd8bba19/attachment-0001.html>