Auto-infer env var names?

[CarlosRDomin]

Hi @alexflint, love this project and I think it's super complete, thanks so much for providing such a helpful library.

We've been using caarlos0/env previously and loved its ability to auto-infer the name of environment variables from the struct field name (e.g. AuthKey becomes AUTH_KEY), as it helps us stay DRY and avoid hard-to-debug issues where someone renames the field but forgets to update the env tag (or vice versa) and configuration doesn't get parsed correctly. Your library is a lot more complete and we'd love to migrate to it, but would love to support "auto-env" tags first (happy to work on an implementation if you think this is something that would get merged).

I was thinking we could either provide a new boolean in the Config struct, something like AutoEnv, which would pre-populate spec.env here if enabled, or perhaps provide a Config.envName func(fieldName string) string that allows users to define any function they want to map a field name to an env name (this way we could remain backwards-compatible and default to strings.ToUpper like you do here). As a reference, here's the function I'd like to provide for this mapping: https://github.com/caarlos0/env/blob/main/env.go#L516-L533

Again, thanks so much for such a comprehensive library!

[alexflint]

Hey @CarlosRDomin , thanks! Yes, I'd be open to adding a DefaultEnvVar func(string) string to the config struct. I'd want to keep the logic where it's only used in the case that "env" is included in the struct tag. I know that means you'd have a lot of struct tags with the same string "env" in them, but without a value. .So this function would replace the use of strings.ToUpper in the part of the code that you point to. It would be great to also add a DefaultOptionName func(string) string in the same PR to do the same with respect to the default long option populated here. If the function returns the empty string in either case then I guess the whole Parse function should fail with an error. Would be happy to accept a PR on this. Thanks again for the note!

[alexflint]

Maybe it should be func (reflect.StructField) string in both cases, to support the case where someone wants to make use of the type to decide on the default name.

[CarlosRDomin]

@alexflint love it! And using func (reflect.StructField) string sounds great!

I'll try to find a bit of time over the holidays and send a PR and ask for feedback :) thanks for the quick response!

PS: would you be willing to add a boolean to Config to enable "env" in all tags if set? It would be backwards compatible because by default it would be set to false, and could save us from forgetting to add "env" somewhere accidentally.

[CarlosRDomin]

@alexflint let me know what you think about #294 :)

[injust]

If we have auto-infer for both environment variable and long option names, a default for placeholder name would be nice.

Personally, I use UPPER_SNAKE_CASE to name both environment variables and placeholders.

[CarlosRDomin]

That's a great point @injust, I didn't realize when working on the (now merged) PR but would be happy to contribute again to apply a consistent casing to both env and placeholders if @alexflint agrees. Just FYI I also opened #295 to control the auto-infer algorithm for long option names

[CarlosRDomin]

Hi @alexflint, any feedback on #295?

[CarlosRDomin]

@alexflint ping :)