Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
It should be possible to use command line parameters extracted via flag.Parse within the init()-ization function of all packages #39093
What version of Go are you using (
The pattern you describe is not recommended in Go. It can only work if the package P1 that calls
This is not an artificial limitation. It's inherent in the design of the flag package.
Multiple calls to
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:
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.
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
You can't know all the flags in an
Of course, an
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.