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

[Sean Hammond]

> > > 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.