Composite application configuration

[Jason]

Hello,

I have a composite application made up of two python packages (I'm bundling applications together to build an ERP system). There is a section for each application in the config file: [app:myfirstapp] and [app:mysecondapp] that have their own configuration. There are several lines that are common between the two applications such as the session and cache configuration. In fact the only thing that must be different is the "use" line.

Is there any way to include a common configuration section for two app sections so that I do not have to duplicate these lines? 

I also checked the http://pythonpaste.org/deploy/ documentation to no avail.

Thanks,

Jason

[cd34]

paster uses pipelines to do that

[app:app1]
use = egg:app1

[app:app2]
use = egg:app2

[composite:main]
use = egg:Paste#urlmap
/ = app1
/app2 = app2

If you need to use exceptions, you can do something like:

[pipeline:pipeapp2]
pipeline = exc tm app2

and in your composite:main

/app2 = pipeapp2

composite is the section you need to read in the docs to understand it
more fully.

[Wyatt Baldwin]

I think what the OP wanted to do was more like this:

[common-app-settings]
x = 1
y = 2
z = 3

[app:app1]
use = egg:SomeEgg
# include common-app-settings

[app:app2]
use = egg:AnotherEgg
# include common-app-settings

[Jason]

Wyatt is correct, I would like some sort of include functionality. My composite configuration works fine (and I am using pipelines and such), but there is a lot of duplication in the app sections.

[cd34]

can you use [DEFAULT]?

[Jason]

I used [DEFAULT] in Pylons for this sort of thing, but it does not work in Pyramid.

[Jason]

I have found that I can do this:

[DEFAULT]

testkey_default = TEST

[app:app1]

testkey = %(testkey_default)s

[app:app2]

testkey = %(testkey_default)s

It causes even more duplication of the config, but it means maintaining the values in a single section.

[Wyatt Baldwin]

I'm using the [DEFAULT] section for this type of thing, but it's a bit wonky IMO and doesn't seem to fit with PasteDeploy's world view. I wish there was an easy way to inherit or mixin config from another section *in the same config file* (yes, I could use `use` to inherit config from another file, but I don't want to maintain N separate config files).

Alternatively, the [DEFAULT] section could work the same way as when using ConfigParser directly, and Paste's "global config" could be pulled from a section called [global_conf] or something like that. That would de-conflate Paste's notion of global config from the normal semantics of the [DEFAULT] section.

[Wyatt Baldwin]

It should work the same way in Pyramid or Pylons, since they both use PasteDeploy to parse and interpret the config file. My config looks something like this:

[DEFAULT]
x = 1

[app:app1]
use = egg:MyEgg
# this should "inherit" x
# If you want to override the global x, you have to use `set` (which is a PasteDeploy thing and is what makes it behave differently from native ConfigParser):
set x = my x

[app:app2]
use = egg:AnotherEgg

# this should also inherit x

[jazg]

Well I can do this:


def main(global_config, **settings):
settings.update((key, val) for key, val in global_config.items()
if key not in settings)


...which means that this would work:

[DEFAULT]
x = 1

[app:app1]

#inherits x
x = my x #overrides x


But if PasteDeploy already supports this with the "set" keyword, can't
we access that functionality somehow? Does pyramid bypass it and parse
the file on its own?

[Jason]

On Friday, September 2, 2011 9:49:48 PM UTC-4, jazg wrote:

Well I can do this: 

def main(global_config, **settings):
    settings.update((key, val) for key, val in global_config.items()
if key not in settings)

...which means that this would work:

[DEFAULT]
x = 1

[app:app1]
#inherits x
x = my x #overrides x

This is what I am now doing, but slightly different.

In the main(global_config, **settings):

settings.update(global_config)

and then if I want to override something that is in [DEFAULT] I use: 

[DEFAULT]

x = 1

[app:app1]

set x = 2

Using the set key overrides it in the global_conf.

-- Jason

[Wyatt Baldwin]

On Tuesday, September 6, 2011 10:27:56 AM UTC-7, Jason wrote:

[...]

This is what I am now doing, but slightly different.

In the main(global_config, **settings):

settings.update(global_config)

and then if I want to override something that is in [DEFAULT] I use: 

[DEFAULT]

x = 1

[app:app1]

set x = 2

Using the set key overrides it in the global_conf.

I noted this in one of my earlier posts (re: set). Also, the way you're updating the settings dict with global_conf will overwrite your app config, won't it? I'm pretty sure the DEFAULT config will end up in the settings automatically anyway.

[Jason]

On Wednesday, September 7, 2011 11:33:47 AM UTC-4, Wyatt wrote:

I noted this in one of my earlier posts (re: set). Also, the way you're updating the settings dict with global_conf will overwrite your app config, won't it? I'm pretty sure the DEFAULT config will end up in the settings automatically anyway.

The DEFAULT config does not end up in the settings (I tried that first).

-- Jason

[Michael Merickel]

Apologies for not following most of the conversation, but just thought I'd mention that in the past I've done:

def main(global_conf, **app_settings):

    settings = global_conf.copy()

    settings.update(app_settings)

Which allows you to override settings in your app if you want while still specifying common setup in [DEFAULT].

Pyramid just uses PasteDeploy to parse the INI file, so any 'set' semantics will still work. Since the settings are not combined by Pyramid, however, I don't think you will gain much by using 'set' over the code I showed above.

--

Michael

[Wyatt Baldwin]

I tested it too, but my test was flawed: I used `paste.deploy.loadwsgi.appconfig`, which merges global config and app config. For some reason, I assumed it would load the config file the same way that `loadapp` does.

[Wyatt Baldwin]

FWIW, I do basically the same thing. I forgot that I'm doing that, because I moved my settings initialization code out of `main`.

With regard to `set`, don't you *have* use it if you want to override a global setting in your app config? It looks like[1] if a config key is present in both the global config and an app section, the setting in the app section is ignored unless you use `set`. This seems counterintuitive to me.

https://bitbucket.org/ianb/pastedeploy/src/8803df83ca09/paste/deploy/loadwsgi.py#cl-428