[WIP] refactor volumes to demonstrate how globals could be avoided #66
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This experimental refactor of the
volumes
commands intends to demonstrate that global variables can be avoided withspf13
usage.Testing these commands should be simpler because the argument and client variables are not set in a global context.
API mocks have been but these are not currently being used by tests (something that I would want to add to validate this approach).
Some of the commands have lost their
json
andyaml
flags in this initial state. I'm interested in seeing if these arguments can become global or if they are best suited for per-command-action use.Relates to #33
Observations and Ponderances:
cmd/*volume*.go
moves to avolume
package ininternal/volumes/
.internal/
,cmd/packet
can be created, which would facilitate Documentgo get
install method #53.go get
would then create binaries with the desiredpacket
name, rather thanpacket-cli
.init()
calls.output
package and functions are created as a way to preserve the existing output functions while moving commands to their own package.Stderr is not used for error messages, neither is spf13's RunEreturn error codes when errors are encountered #70 error messages duplicate and error code is still not reported #75Example
field, rather than using theLong
field. I can see whyLong
was used to portray examples, and I think this was to avoid the short description from being repeated in the help and generated markdown. I think a better experience can be had by providing meaningful content in the long description fields.