Implement shared context command in genericCLI #194
Conversation
…e connect & Msg
Unfortunately, I don't see any space for meaningful simplification without introducing changes for users. |
| } | ||
|
|
||
| func (c *Context) GetAPIToken() string { | ||
| // TODO ensure consistency |
There was a problem hiding this comment.
Can you elaborate on this TODO?
There was a problem hiding this comment.
CLI tends to fallback to cmd arguments, but this patters is not universal. Are there any requirements/ideas on this behaviour?
There was a problem hiding this comment.
Not sure where the consistency issues is here.
In general we have the following priorities:
- if there is a flag, use it (viper takes care of this)
- if there is an env, use it (viper takes care of this)
- rely on the config file
vknabel
left a comment
vknabel
left a comment
There was a problem hiding this comment.
Test structure looks good IMHO. Will still have a more in depth look on the individual test cases.
| // Console tests below | ||
|
|
||
| type consoleTestCase[T any] struct { |
There was a problem hiding this comment.
Maybe, and I am not sure, it makes sense to create two separate test files here. One for the context manager tests from the usage perspective and one from the console perspective.
There was a problem hiding this comment.
I had the same idea initially, but I decided to keep it in one file for better integration. The IDE automatically picks it up as the test file for context.go.
…m implementation for the sake of consistency
Description
Closes #191