#33190

The pattern you describe is not recommended in Go. It can only work if the package P1 that calls flag.Parse from init is known to import all other packages that define flags. If the main package imports some package P2 that defines a flag, but P2 is not imported, directly or indirectly, by P1, then there is no way to know whether the flags defined by P2 will be seen when parsing flags.

This is not an artificial limitation. It's inherent in the design of the flag package.

Multiple calls to Parse would not help. At the time of the first call to Parse we can't know whether there will be subsequent calls, so we can't know whether to report an unknown flag or not.

We aren't going to change the flag package or the testing package. For your use case, consider using a different flag package.

First I would like to mention that I don't want to go against the current or against the best technical model. I don't want to challenge anything. That being said:

Question/Problem:

How would it then be correct to have packages use in their init() functions values that come from the cli? This is a simple question.
By comparison, one is able to use env vars within all init() without breaking anything, why wouldn't this be possible with cli flags? ALL the flags do exist at the moment of the executable invocation / loading by the OS, just like env vars, why can't we rely on them? Doesn't this look like an artificial limitation that we cannot use equally available resources (user provided config values) in the same way?

What I was (maybe naively) suggesting was that each package could register its set of flags it would be interested in and call Parse on its own to discover the values of the flags registered so far. This would not rely on the pattern of imports you describe above since each interested package could not only register flags, but try to fetch those already registered. Obviously, the Parse caller is interested in the flags it just defined moments before, not in the flags that any different package may define for its own use later.

Is there another way for the question above except using something totally different than Parse?

Thanks for your patience, hope this explains it a tad better.

With the syntax used by the standard library flags package, you can't parse flags if you don't know all the flags, because when you see -z arg you don't know whether arg is a value for -z or whether -z is a boolean flag that doesn't take a value.

You can't know all the flags in an init function. It's not possible in Go. So with the syntax used by the standard library flags package, you can't parse flags in an init function.

Of course, an init function can look at the command line, by using os.Args. So if you are able to unambiguously parse the command line without knowing all the flag definitions, then any individual package can look at os.Args and extract whatever information it likes.

There's nothing with doing things that way if you like. It's just not how the standard library flags package works, and it's not possible for the standard library flags package to work that way.

Ok, thanks for the explanation. It does make sense, even if I don't like the limitation per se :)
Thank you very much!