You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm refurbishing configuration format of an application with the below scenario/requirements:
Say, the application runs in two environments, production and development.
Content in configuration should be all relevant to the environment it's within, and not affected by irrelevant items required by other environments for readability:
(Ideally it should be like):
settings.yaml [development]:
# I'm currently in development environment.db_name: "db"db_user: "user"db_password: "pw"
settings.yaml [production]:
# I'm currently in production environment.db_name: "db"db_user: "user"db_ssl_cred: "/path/to/cred"db_proxy: ... # Some nested configuration
(instead of): settings.yaml
# I'm currently in development environment...default: # Relevantdb_name: "db"db_user: "user"development: # Relevantdb_password: "pwd"production: # Noisedb_ssl_cred: "/path/to/cred"db_proxy: ... # Some nested configuration
Although I don't like "noisy" configuration file, I'm entirely fine with placing validators together, because it's more convenient to look up options and constraints in one place when writing up configuration file for specific environment.
This is what works for the second ("noisy") solution:
But I'm not certain what's the recommended way to implement configuration and validation in the first ("ideal") solution, due to the fact that Dynaconf's configuration setup heavily sticks to environments flag:
For instance, env, force_env, and env_switcher (though documentation does not mention env_switcher gets omitted when environments is disabled) requires environments flag to work correctly.
When environments flag is disabled, while it's still possible to overwrite environment through env parameter and make it available in Settings.ENV_FOR_DYNACONF (another complaint: it's alwaysENV_FOR_DYNACONF even when env_switcher is given. So if you set env_switcher to something like MY_APP_ENV and get else things right, accessing Settings.MY_APP_ENV will fail, tragically.), all other configurations/validations will not respect this and turn back to default settings (assuming the "main" environment).
Enabling environments, however, forces using multi-layered environment format, defines everything altogether, thus leads to the "noisy" solution.
One of the solutions I can think of is to apply different setup by identifying specified environment variable explicitly:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all,
I'm refurbishing configuration format of an application with the below scenario/requirements:
Say, the application runs in two environments,
production
anddevelopment
.Content in configuration should be all relevant to the environment it's within, and not affected by irrelevant items required by other environments for readability:
(Ideally it should be like):
settings.yaml [development]
:settings.yaml [production]
:(instead of):
settings.yaml
Although I don't like "noisy" configuration file, I'm entirely fine with placing validators together, because it's more convenient to look up options and constraints in one place when writing up configuration file for specific environment.
This is what works for the second ("noisy") solution:
But I'm not certain what's the recommended way to implement configuration and validation in the first ("ideal") solution, due to the fact that Dynaconf's configuration setup heavily sticks to
environments
flag:env
,force_env
, andenv_switcher
(though documentation does not mentionenv_switcher
gets omitted whenenvironments
is disabled) requiresenvironments
flag to work correctly.environments
flag is disabled, while it's still possible to overwrite environment throughenv
parameter and make it available inSettings.ENV_FOR_DYNACONF
(another complaint: it's alwaysENV_FOR_DYNACONF
even whenenv_switcher
is given. So if you setenv_switcher
to something likeMY_APP_ENV
and get else things right, accessingSettings.MY_APP_ENV
will fail, tragically.), all other configurations/validations will not respect this and turn back to default settings (assuming the "main
" environment).environments
, however, forces using multi-layered environment format, defines everything altogether, thus leads to the "noisy" solution.One of the solutions I can think of is to apply different setup by identifying specified environment variable explicitly:
Or adding configuration stating the environment, though seems somewhat redundant:
Any better ideas?
Beta Was this translation helpful? Give feedback.
All reactions