add a way to prefer environment over settings #16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Describe the change
Adds an (optional) way to prioritize environment over settings.
This is done with the following changes:
@preferred
instance variable, getter, and a validating setter. It takes one of two values::settings
(default) - this is how it currently works without this change: check settings first, falling back to environment.:environment
- reverses the standard lookup order: checking environment first, then settings as a fallback.prefer(source)
as an alias forpreferred=(source)
, because it reads nicely.TTY::Config::UnsupportedSource
exception for when told to prefer an unrecognized source.TTY::Config.normalize_preferred(source)
method that allows several intuitive source names to be normalized to one of the correct values:settings
,configuration
,config
,file
, andfiles
all becomesettings
, because that seems to be whatTTY::Config
refers to the config file values as.environment
,env
, andENV
all becomeenvironment
.TTY::Config#fetch
:prefer
, allowing this to be overridden on a per-fetch basis if desired.The naming of these things can of course be adjusted if they're not internally consistent with TTY's naming style.
When selecting the aliases above, consideration was given to how the code would read in both contexts:
Since the
: :
bit is a bit ugly (IMO), the option can be passed as a String (technically anything that responds toto_sym
, but I'm really not sure what else one would WANT to pass in... and either way the validation will catch it).Why are we doing this?
From my perspective, I usually want environment to take priority over a config file, if a value is defined in both. Kind of like how I want options given on the command line to take priority over either, y'know? In my head, it's something like this:
tty-option
thing).I recognize that what's intuitive to me, may not align with others, so this change leaves the choice up to the developer.
Benefits
Allows developers using
tty-config
to choose whichever order suits their needs.Drawbacks
One more option to configure, I suppose. But it's optional, and it defaults to working the way it does already, so I don't see any obvious drawbacks.
Requirements
master
branch?