vsoch
commented
1 year ago We could move to a config file or env-based approach. The challenge would be lots of changes to config.py to optionally read every variable from the file or env before falling back to a default/initial value. This approach is also challenging for representing non-string / non-numeric configuration settings (booleans, lists).
I think I actually really like this approach? I made the original sregistry a long time ago, but since then I've made (by default) most of my Django apps read everything in from either a config file or the environment. E.g., here is an example that allows loading in from a config.yaml or the environment:
And then the defaults could be set in multiple ways, e.g., here is an example (for a Django plugin) that has a defaults structure and then can override it (in our case it would be from a settings file or environment):
What do you think?
cpeel
Improve the k8s deployment experience by making override updates to
settings/local.pyrather than changing the entiresettings/config.py, like was done in the helm templates referenced in https://github.com/singularityhub/sregistry/issues/317. A single container can now be built for use in dev/stg/prd environments and use an updated helm manifest to override values that differ in each env. This also improves the dev & upgrade experience by having local settings not pollute code under source control.Pros/cons of this approach:
config.pyif they want).local.pyeverything continues to work.secrets.py).local.pyvsconfig.py) requiring several doc updates.config.pyintolocal.py.Other approaches considered:
config.pyto optionally read every variable from the file or env before falling back to a default/initial value. This approach is also challenging for representing non-string / non-numeric configuration settings (booleans, lists).secret.pyand have them picked up and overrideconfig.py. This hacky approach convolutes the separation of secrets vs configuration data.