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

[Adrià Mercader]

I'm a big +1 on strict namespacing at least at 2 levels:

ckan.search.{...}
ckan.auth.{...}

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


The tests sound also good


Adrià


On 30 April 2013 13:55, Sean Hammond <sean.hammond at okfn.org> wrote:
>> > > 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.
>
> _______________________________________________
> 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