okfn/ckan — pull request #879 by tobes (2013-06-07 11:05:00+00:00)
Title: config and globals refresh

Aims

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) and test-core.ini (auto-generated?)

Some comments from the email thread

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

Also having the same convention for extensions:
ckanext.spatial.{...}
ckanext.pdeu.{...}

- options with docstrings that really don't explain what the option does
- options that don't actually work as documented
- options that should be marked as deprecated
- options that should be marked as beta or experimental
- options that should be renamed to group related options together
- options that are still missing from these docs, despite Vitor's
efforts to find them all

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.