Allow loading settings from outside of the postgresqleu tree

[mwanner]

To ease building docker images and prevent having to maintain an
in-tree file for local settings, allow a pgeu_system_settings
module anywhere in the PYTHONPATH for configuration.

In addition, also allow overrides to be applied after loading the
skin.

[mhagander]

I like this idea in general. In fact, I think something like this can be used to significantly simplify some of the hacks around the deployment we do on pginfra as well! But I think the ordering s wrong :)

Today we have:

1. local_settings
2. skin_settings
3. skin_local_settings (which I think are similar to your override ones)

I think what you're adding is basically "site settings", so shouldn't they be loaded before local_settings?

In a lot of ways, local_settings should be loaded last. The reason they're not loaded last toay is that local_settings is where you define the SKIN_DIRECTORY. So there's kind of a chicken and egg situation there. I think your idea of splitting it into two makes a lot of sense -- but it should then also be done for local_settings, as in it should have a similar override:ability.

So I'm thinking maybe something like this (open for discussions):

1. pgeu_system_settings module
2. local_settings.py (needs to be early to set skin settings)
3. if skin then skin_settings
4. if skin then skin_local_settings
5. pgeu_system_override_settings module
6. local_settings_override.py

Or something like that. If seems wrong that "system settings" would override "local settings"...

[mwanner]

Thanks for your consideration.

So I'm thinking maybe something like this (open for discussions):

1. pgeu_system_settings module

2. local_settings.py (needs to be early to set skin settings)

3. if skin then skin_settings

4. if skin then skin_local_settings

5. pgeu_system_override_settings module

6. local_settings_override.py

I agree and like this order. I'll try to adjust the PR accordingly.

Or something like that. If seems wrong that "system settings" would override "local settings"...

This could be more of a naming issue. The entire project is called pgeu_system, so the system part is more of the original same (the python module is called postgresqleu, though, maybe I should use that instead). The intent for these was just to be override settings. E.g. to override ENABLE_PG_COMMUNITY_AUTH that a skin sets, but you may not want to enable for a local test setup during development.

Do we need two different override modules?

To avoid bike-shedding as much as possible, I tend to just s/pgeu_system/postgresqleu/ as the base name. And go with settings, local_settings, and override_settings. Times two, if we really need a local vs system wide variant for each.

[mhagander]

Or something like that. If seems wrong that "system settings" would override "local settings"...

This could be more of a naming issue. The entire project is called pgeu_system, so the system part is more of the original same (the python module is called postgresqleu, though, maybe I should use that instead). The intent for these was just to be override settings. E.g. to override ENABLE_PG_COMMUNITY_AUTH that a skin sets, but you may not want to enable for a local test setup during development.

Oh. Gotcha. I did not realize it came from that :) With that it makes a lot more sense.

Do we need two different override modules?

Maybe? When deploying to multiple different servers (like we do for pginfra for example), having the module mentioned in point 1 above makes sense. It would be a good place to put things like logging configurations.

And then the usecase that you mention have use for the module in point 5?

To avoid bike-shedding as much as possible, I tend to just s/pgeu_system/postgresqleu/ as the base name. And go with settings, local_settings, and override_settings. Times two, if we really need a local vs system wide variant for each.

I don't think changing the base to postgresqleu is a good idea because for historical reasons that's the base name of the modules in the code itself. It's better to keep them apart.

So maybe pgeu_system_override is the right thing. And maybe make the other one pgeu_system_global_settings or something, to indicate it's loaded on top before the others?

[mwanner]

@mhagander I updated this PR, please take another look.

[mhagander]

(I'm back from the mostly dead wrt this project)

The changes to tools/devsetup/dev_setup.sh kind of feels like they're left-over from something that did more? I'm not sure as they stand now they're really an improvement?

The rest I think looks pretty good now. I think I'll add a pure "list of the order of processing" in the readme file, but I can do that as part of a merge.

[mwanner]

(I'm back from the mostly dead wrt this project)

Thanks for reviewing, welcome back! ;-)

The changes to tools/devsetup/dev_setup.sh kind of feels like they're left-over from something that did more? I'm not sure as they stand now they're really an improvement?

Correct, I think I intended to provide an alternative command using the newly introduced pgeu_system_global_settings.py, but in the end made it a comment, only.

I'm happy removing the logical changes and leaving just a comment.

The rest I think looks pretty good now. I think I'll add a pure "list of the order of processing" in the readme file, but I can do that as part of a merge.

[mwanner]

Adjusted accordingly. @mhagander

[mhagander]

This has been merged. Thanks!