-
-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor environment variable handling into new Sources::EnvSource #299
Conversation
merge!(hash) | ||
end | ||
|
||
alias :load_env! :reload_env! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pkuczynski Config::Options#load_env!
and Config::Options#reload_env!
are not documented at all, but are technically public
methods.
As such, depending on whether or not we consider all visible methods to be part of the public API of this gem, this could be considered a breaking change and warrants a major version bump, so I added this under Breaking Changes
in the changelog.
The change for users that use #load_env!
or #reload_env!
is simple: they should just replace those usages with #reload!
, which is documented.
814a26f
to
1750953
Compare
By default, EnvSource will use "global" settings specified like `Config.env_prefix`, `Config.env_separator`, `Config.env_separator`, and `Config.env_parse_values`. Those configurations will be used when parsing the ENV hash. But when using EnvSource to load settings from some unrelated flat string-keyed Hash source, we want to allow folks to override the settings.
@pkuczynski let me know if you have any concerns |
Ended up speaking to @pkuczynski about this in another channel. He's cool with merging and releasing. This change was released in 3.0.0. |
…ubyconfig#299) * Extract env var handling to new EnvSource class * Allow overriding settings for parsing env sources By default, EnvSource will use "global" settings specified like `Config.env_prefix`, `Config.env_separator`, `Config.env_separator`, and `Config.env_parse_values`. Those configurations will be used when parsing the ENV hash. But when using EnvSource to load settings from some unrelated flat string-keyed Hash source, we want to allow folks to override the settings. * Update CHANGELOG * Add AWS Secrets Manager usage to README
In principle, loading settings from environment variables isn't much different from loading them from a
YAMLSource
or aHashSource
. This change unifies the handling of environment variables into the existing "sources" abstraction.My own personal motivation for this change is essentially the same as #271. I want to load settings into
config
that I got from AWS Secrets Manager. Although AWS Secrets Manager's API technically allows you to store arbitrary string values, the AWS Console UI and the AWS Secrets Manager API encourages you to store your application's secret configuration as as single Secret resource that is a flat, JSON-encoded key-value mapping. This maps very nicely to how one might use environment variables to configure an application.Editing secrets in the AWS console
Actual plaintext
The problem is that while
config
offers the ability to parse nested settings fromENV
, it doesn't allow you to do the same for settings you got from another source, like AWS Secrets Manager. As a result, users are forced into an awkward workaround: export all secrets from AWS Secrets Manager intoENV
, then askconfig
to load theENV
again. My proposedEnvSource
allows users to skip the loading-into-ENV step and just hand the flatHash
over toconfig
directly.For example,