-
Notifications
You must be signed in to change notification settings - Fork 0
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
Introduce config.FromEnv() #41
Conversation
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.
In general, this PR looks good. However, there is still at least one bug for the logging options, as unveiled by the tests I have just written and committed in 0ebbcb6. Please consider including this commit in your PR.
I'd like to see 0ebbcb6 as a PR from you with multiple commits into my branch. |
The diff itself now looks kinda good. Thanks! Would you mind start using this branch in one application and implement this change and creating a draft PR? Doing so allows testing this PR outside of tests and, if everything works, gives us more certainty before merging it and even tagging a release. |
The purpose of tests is exactly not needing what you suggest for more certainty. |
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.
Are the tests for the concrete config types just to verify the environment variable names, or do they add something specific? Just wondering since we don't do this for YAML keys (yet).
config/config.go
Outdated
return errors.Wrap(err, "can't parse environment variables") | ||
} | ||
|
||
return errors.Wrap(v.Validate(), "invalid configuration") |
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.
If I'm not mistaken, we've discussed in other PRs whether we should reduce error checks before return
by directly returning errors.Wrap()
(as it handles nil
), but I'm not entirely sure we've agreed on doing that or not. Compared to the validate handling in FromYAMLFile()
, the reduced version here gives the first impression that it will return an error.
I opt for not returning errors.Wrap()
if the error could be nil
as a rule.
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.
Personally, since I discovered that errors.Wrap()
also handles nil errors, I do tend to use it as the last statement as well, instead of using an if statement and returning nil at the end. However, @oxzi also requested a change in #63 (comment) for not using it for readability reasons, so if you think this makes the code more readable/understandable, we can make it the standard.
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.
In the referenced comment, I primarily wanted a consistence between the two checks. Furthermore, when I am reading errors.Wrap(…)
, I am expecting an error to be handled and wrapped. Adding the if guard makes it more readable, imo. But honestly, I am fine with both.
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.
Ok, I'd like to define this now: Don't return errors.Wrap()
directly if the error could be nil
.
config/config_test.go
Outdated
@@ -0,0 +1,101 @@ | |||
package config |
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.
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.
@Al2Klimov Please only fix the direct errors.Wrap()
return. Tests will be adjusted with #77.
config/config.go
Outdated
return errors.Wrap(err, "can't parse environment variables") | ||
} | ||
|
||
return errors.Wrap(v.Validate(), "invalid configuration") |
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.
Ok, I'd like to define this now: Don't return errors.Wrap()
directly if the error could be nil
.
By implementing the encoding.TextUnmarshaler, Options can be populated by environment variables from env.
Test everything related to config
I already fixed the direct return of |
FromEnv parses environment variables and stores the result in the value pointed to by v.
If v is nil or not a pointer, FromEnv returns an ErrInvalidArgument error.