-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add initial boilerplate #1
Conversation
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking nice 🌹 Not much to add, minus @onprem's comments
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
@@ -0,0 +1,19 @@ | |||
package cmd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about grouping all *_metrics.go
under this single file, for easier access and readability? Do we need one subcommand per file?
Alternative: Put all in a cmd/metrics/*
sub-directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might be subcommands of subcommands too. So I just put each logical top-level separate command in a separate file here. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm then how about the other suggestion with sub-directories? That way we could nicely represent the relationship between parent-children commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into this a bit more, about how cobra-based CLIs are organized on other projects (e,g kubectl/skaffold). Let's actually go with the single metrics.go
file approach for now! Creating subdirs would require new packages for each top-level command and make sharing stuff like logger
much harder.
And instead of having each command as a global variable with init
functions to add flags (as suggested by cobra), it'd be better to add functions for each new command and use that (like in other projects). Makes it much more organized! 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, thanks for addressing this!
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Have added all the initial commands that we plan for now! Likely this will change a lot once we actually implement the functionality. 🙂 |
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
15f4b65
to
969d235
Compare
var logLevel, logFormat string | ||
var logger log.Logger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not too keen on having global variables, I think we can create wrappers around the Run functions and pass loggers in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just had a small non-blocking comment, but we can tackle that in future PRs. LGTM!
This PR adds the initial boilerplate for obsctl.
kingpin
)