Skip to content
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

Merged
merged 14 commits into from
Oct 22, 2024
Merged

Introduce config.FromEnv() #41

merged 14 commits into from
Oct 22, 2024

Conversation

Al2Klimov
Copy link
Member

@Al2Klimov Al2Klimov commented Jul 17, 2024

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.

@Al2Klimov Al2Klimov added the enhancement New feature or request label Jul 17, 2024
@cla-bot cla-bot bot added the cla/signed CLA is signed by all contributors of a PR label Jul 17, 2024
Copy link
Member

@oxzi oxzi left a 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.

config/config_test.go Outdated Show resolved Hide resolved
config/config_test.go Outdated Show resolved Hide resolved
logging/config.go Show resolved Hide resolved
@Al2Klimov
Copy link
Member Author

I'd like to see 0ebbcb6 as a PR from you with multiple commits into my branch.

@lippserd
Copy link
Member

lippserd commented Aug 5, 2024

I'd like to see 0ebbcb6 as a PR from you with multiple commits into my branch.

@oxzi Please wait before you do that (at all). I would like to do my review first.

@oxzi
Copy link
Member

oxzi commented Sep 4, 2024

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.

@Al2Klimov
Copy link
Member Author

The purpose of tests is exactly not needing what you suggest for more certainty.

Copy link
Member

@lippserd lippserd left a 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 Show resolved Hide resolved
config/config.go Outdated
return errors.Wrap(err, "can't parse environment variables")
}

return errors.Wrap(v.Validate(), "invalid configuration")
Copy link
Member

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.

@yhabteab @oxzi Please add your opinion.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

@@ -0,0 +1,101 @@
package config
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these tests are of any value as I have first have to understand what this code is actually doing. See #71 for my approach. Though I'd wait for #71 before changing tests here.

Copy link
Member

@lippserd lippserd left a 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 Show resolved Hide resolved
config/config.go Outdated
return errors.Wrap(err, "can't parse environment variables")
}

return errors.Wrap(v.Validate(), "invalid configuration")
Copy link
Member

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.

@lippserd
Copy link
Member

@Al2Klimov Please only fix the direct errors.Wrap() return. Tests will be adjusted with #77.

I already fixed the direct return of errors.Wrap().

@lippserd lippserd self-requested a review October 22, 2024 14:42
@lippserd lippserd merged commit 4c2f63f into main Oct 22, 2024
15 checks passed
@lippserd lippserd deleted the FromEnv branch October 22, 2024 14:42
@julianbrost julianbrost modified the milestones: 0.5.0, 0.4.0 Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla/signed CLA is signed by all contributors of a PR enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants