Hi Ben, The code snippet in my previous email was cut off so the key "sqlalchemy.ur" is not the problem. Here is actual code I'm using: http://dl.dropbox.com/u/374620/myapp.tgz
As you pointed out, accessing the runtime configuration outside of the bounds of a request is not going to work. Since this behavior is different from Pylons 0.9.7 I wanted to make sure that it wasn't a bug. Given that the behavior is by design, I have some followup comments and questions. Up until now I've been following these pieces of Pylons documentation: http://pylonshq.com/docs/en/1.0/configuration/#run-config http://pylonshq.com/snippets/running_commands_with_the_app_environment The first piece recommends using "pylons.config" to access the runtime configuration and the second recommends using load_environment() to run commands with the app environment outside the bounds of a request. Obviously the second piece of documentation isn't valid anymore. Personally, I find it very useful to access the runtime configuration outside the bounds of a request because it makes it much easier to write unit tests and it also makes writing scripts much easier. I shouldn't have to setup a WSGI app in order to use the models and library functions in my package. Going forward it seems like there are a few options: 1) make "pylons.config" available outside the bounds of a request 2) set "pylons.config" to the runtime configuration in myapp.config.environment.load_environment() 3) add a package-level reference to the runtime configuration in load_environment() (e.g. {{package}}.config = config) 4) update the documentation and recommend that custom runtime configuration should happen inside load_environment() rather than by accessing "pylons.config". I definitely see the appeal to having an app-local runtime configuration but it's going to cause problems for people upgrading from 0.9.7. That's not necessarily a reason to change the behavior of "pylons.config" in 1.0 but it is a reason to update the documentation and publish a recommendation for how to enable runtime configuration outside the bounds of a request. -Andres On Mar 27, 5:33 pm, Ben Bangert <[email protected]> wrote: > On Mar 26, 2010, at 9:03 AM, andres wrote: > > > > > > > This works fine within the context of a WSGI app instance but outside > > the context of an app instance (e.g. testing environment), the config > > object is a bare-bones pylons config rather than the runtime > > configuration I expect. For example, if I create a simple library > > function to test for the presence of a runtime config key: > > > # myapp/lib/util.py > > from pylons import config > > > def has_config_key(key): > > return key in config > > > then I see the following behavior when I run this test: > > > # myapp/tests/functional/test_runtimeconfig.py > > from myapp.tests import TestController > > from myapp.lib.util import has_config_key > > > class ConfigTest(TestController): > > def test_app(self): > > response = > > self.app.get(url(controller='proxy',action='util_has_config_key',key='sqlal > > chemy.ur')) > > self.assertEqual('True' in response.body, True) > > Your key here is 'sqlalchemy.ur', was that supposed to be 'sqlalchemy.uri'? > When I make a function like this, and test for the value, it works fine on > 1.0RC1. > > > def test_func(self): > > haskey = has_config_key('sqlalchemy.url') > > self.assertEqual(haskey, False) > > This isn't going to work because the config object is not setup outside the > bounds of a request, as none of the globals are. If you would like to look at > the config object in a unit test, outside the bounds of a request, you can > get to it as the config attribute off the app object like so (when running > unit tests, this will exist): > > import pylons.test > > assert 'something' in pylons.test.pylonsapp.config > > Otherwise you'll want to use loadapp like Mike Orr referred to. > > Cheers, > Ben -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
