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

added WithGetenvFunc option #131

Closed
wants to merge 1 commit into from
Closed

Conversation

tempcke
Copy link

@tempcke tempcke commented Feb 17, 2024

added WithGetenvFunc option so that from tests we do not have to rely on global state, defaults to os.Getenv still

… on global state, defaults to os.Getenv still
@tempcke
Copy link
Author

tempcke commented Feb 18, 2024

just to add some color as to why this is useful. I had the idea after reading Mat Ryer's post https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/

where he calls run from main() with

func run(
	ctx    context.Context,
	args   []string,
	getenv func(string) string,
	stdin  io.Reader,
	stdout, stderr io.Writer,
) error

which allows him to test everything without worrying about conflicting global state and I really liked the idea.

@peterbourgon
Copy link
Owner

peterbourgon commented Feb 18, 2024

I don't think I grok the use case, here. In any case that you would pass a "getenv" func that pulled from something other than the true os.Environ, why wouldn't you pass flags as args directly?

edit: Is it just about tests?

@tempcke
Copy link
Author

tempcke commented Feb 19, 2024

yes, the only time you would ever not pass in os.Getenv is when trying to write a test against run itself. This change hurts nothing and changes no existing behavior but it does add a slight advantage to testing.

Even in your own tests you are setting the env vars and then defer them back to the original values and can not run tests in parallel because of it.

@peterbourgon
Copy link
Owner

Got it.

This change hurts nothing and changes no existing behavior but it does add a slight advantage to testing.

I don't agree. Every addition to the API of a module adds cognitive overhead and complexity -- costs that need to be justified with commensurate benefits. This is a non-trivial change with benefits that aren't immediately clear to me. Just need to think it through.

@peterbourgon
Copy link
Owner

Doesn't seem like this juice is worth the squeeze.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants