Introduce a notion of 'environment'

[inklesspen]

Bundle app config, server config, logging config into a single thing, loadable by name.

[sontek]

Yeah, I think something like this:

dev:
    application:
        foo: bar

    server:
        biz: baz

    logging:
        qix: quz

prod:
    ....

would work best because then when you load it up pyramid -c app.yaml -e dev serve

[inklesspen]

Unfortunately that is exactly inverted from how PasteDeploy does things, and since backwards compatibility is the only way Montague will get adoption, we're more likely to see something like this:

application:
    dev:
        foo: bar
    prod:
         foo: baz

Though of course your custom loader is free to rewrite one into the other.

[sontek]

@inklesspen That doesn't work because the structure is:

{
    "globals": {},
    "application": {},
    "composite": {},
    "filter": {},
    "server": {},
    "logging": {},
}

and when you load an "environment" you want the server and logging configuration to change at the same time. You don't have the same logging or server in dev that you have in prod.

[inklesspen]

@sontek sure, but you'd have a 'dev' key under application, logging, and server that way. (or if you didn't have a 'dev' key, it would probably fall back to 'main')

As an example, Mimir has a toml config file (well, it has a Mako template that renders to toml) with this sort of setup. There's a development key in application, server, and logging; currently the bundled scripts require you specify the key you want for each of those three things, but there's no reason there couldn't be an 'env' command line option that uses the same key for each of the three.

[sontek]

Yeah, I see what you are getting at. More verbose and less organized but it works

[inklesspen]

Well, we're programmers. We can rearrange things all we like. I was just super lazy and had the TOML format mirror the format required in the API. There's no reason you would also have to do that.