I think this is achievable many idiomatic ways today, so I'm not sold on adding another API function. You could use an init function or a func enclosure that returns the var. I also think this is generally a bad practice because (a) you should have a concrete config type and (b) it makes testing a nightmare.

What problem are you trying to solve by not having the parsing in main?

I think this is achievable many idiomatic ways today, so I'm not sold on adding another API function. You could use an init function or a func enclosure that returns the var. I also think this is generally a bad practice because (a) you should have a concrete config type and (b) it makes testing a nightmare.

What problem are you trying to solve by not having the parsing in main?

These are all perfectly reasonable questions. If this isn't accepted, I totally understand. 😄

This came about from looking at how we've used envconfig (Kelsey's version), which generally follows this form:

package main

type env struct {
  Port        int    `envconfig:"port", required:"true"`
  BackendAddr string `envconfig:"backend", required:"true"`
  ... etc.
}

func main() {
  var env env
  if err := envconfig.Process("", &env); err != nil {
    log.Fatalf("bad env: %v", err)
  }
  ... use env.BackendAddr, etc.
}

This is ...fine. Some examples define type env struct inside func main(), a couple do it in func init to get it out of func main(), there's maybe half a dozen similar ways to do it. I do realize I'm proposing another one. 😆

In any case, our usage tends to be only inside package main, where we generally don't have a need to test the type. It's generally a shortcut for os.Getenv and verbose manual error-prone validation. The env values usually go straight in to a client setup and the client gets passed to a type that does the real work, and gets tested that way. The type is usually concretely defined today, but is unexported from package main so it doesn't really amount to much.

My line of thinking was roughly:

1. we always log.Fatal when Process returns its err; why not just have MustProcess (Kelsey's has this, but it doesn't return the value) -- this saves 2 lines of boilerplate.
2. when we have MustProcess, it could return the value -- this saves another line of boilerplate.
3. when we have a one-liner, it could go into the package-level var definition, with some anonymous struct contortions -- this lets us move it out of func main().

That line of thinking might be flawed, or overly clever, but that's how I got to this approach.

If this isn't considered an idiomatic way to use the library, I'll accept that. Thanks for this library, and for your thoughtful response 😄

@imjasonh I cleaned this up and updated docs in #115

@imjasonh I cleaned this up and updated docs in #115

Thanks! 😍