-
Notifications
You must be signed in to change notification settings - Fork 59
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
Allow nested subcommands a chance at modifying the Context #101
Comments
In situations like this, the solution is usually to put a sort of configuration object into the context, with reference semantics. This allows "deeper" layers of code to write information that can be subsequently read by "higher" layers of code, without needing to play games with wrapping or run multiple passes. ctxdata is an example of this pattern. Would that solve your use case? |
But, I would probably caution against putting stuff like the client (in your example) into a context. If some code depends on a client in order to do its job, providing it through a context has the effect of hiding it, and makes it easy to forget to provide it. A client should probably be expressed as an explicit dependency, so it becomes a clear part of the API contract, visible, testable, etc. For that particular example, I'd suggest taking a look at the two-phase approach used by the objectctl example. It has a client that's instantiated after the command tree is parsed in the parse phase, and can then be consumed by any subcommand during the run phase. |
Thanks for the thoughtful response, I've been using ff/ffcli for a few years now very happily.
Definitely agree, my contrived example wasn't great. Something a little more realistic is Your suggestion of |
Then I'm not sure I understand what you're after. If someone does edit: This maybe seems like some kind of hierarchical set-up or initialization code? That is, pretend each subcommand had a If that's right, then you can solve this in a similar way to shared global flags in the
It's easy to imagine a helper utility to compose Exec functions with ancestral setup functions. |
I agree.
Right on. What you describe is exactly what I am after.
This is what I do today. I do think I will pursue the helper utility you're describing. Thanks again for your time, I'll share the end result if I come up with anything worthwhile. I think we can close this now |
I have created a CLI using
ffcli
that has multiple tiers of subcommands. Some subcommand trees have different requirements than others. For a contrived example, one subcommand tree needs to produce one type of client, and one subcommand tree needs to produce another type of client.I would like to populate the
context.Context
passed from the root command viaRun(context.Content)
with computed information that is dependent on the subcommand tree root, such that if the command isfoo setup bar <....>
wherebar
is a subcommand ofsetup
,setup
gets a chance to modify the context being passed through.I am thinking along the lines of how things like
logr.FromContext()
works, as a means of loosely coupling my layers that have distinct needs.The text was updated successfully, but these errors were encountered: