-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Adds Persistent{Pre,Post}Run hook chaining #1253
Conversation
baf1dd8
to
22954be
Compare
Thanks @poy for the contribution. We recently discussed this topic in #1198 and with my limited experience, I got the impression that the current behaviour allowed for the most flexibility. It allows to either override an ancestor's PersistentPreRun function by defining one in a subcmd, and it allows to extend ancestor's PersistentPreRun by calling them explicitly from a subcmd. I'm trying to compare the value of this PR's new approach with the current one. Could you explain a little more how your change will change current behaviour, and why it is better? I'm also curious if this change is breaking? Existing programs that have PersistentPreRuns will behave differently with this change? This was mentioned in #252 (comment). |
955c56c
to
a51d94f
Compare
This PR will allow a user to create a hierarchy of This is not a breaking change (now :) as this behavior only takes place when |
a51d94f
to
f82d6f2
Compare
Is there any chance of this being merged? |
@marckhouzam A gentle reminder to review (and merge) this PR when free 😄 |
I'm not a maintainer 😉 |
@poy Could you instead call |
Yes. However, I think given the name "Persistent", it shouldn't be required. PersistentFlags for example don't have to be added in this way. |
This PR is being marked as stale due to a long period of inactivity |
Would still love for this to be considered. |
PersistentPreRun and PersistentPostRun are chained together so that each child PersistentPreRun is ran, and the PersistentPostRun are ran in reverse order. For example: Commands: root -> subcommand-a -> subcommand-b root - PersistentPreRun subcommand-a - PersistentPreRun subcommand-b - PersistentPreRun subcommand-b - Run subcommand-b - PersistentPostRun subcommand-a - PersistentPostRun root - PersistentPostRun fixes spf13#252
Hey all. |
@marckhouzam what is required to have this PR merged (now that you are a maintainer 😄) ? |
@@ -102,6 +102,21 @@ type Command struct { | |||
// * PersistentPostRun() | |||
// All functions get the same args, the arguments after the command name. | |||
// | |||
// When TraverseChildrenHooks is set, PersistentPreRun and |
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.
Maybe worth adding something like By default, if PersistentPreRun or PersistentPostRun is set, the parent's Pre/Post run hooks are not executed
?
// TraverseChildrenHooks will have each subcommand's PersistentPreRun and | ||
// PersistentPostRun instead of overriding. It should be set on the root | ||
// command. | ||
TraverseChildrenHooks bool |
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 think it's worth adding some checks to ensure that this is set in the root command only (because traverseChildrenHooks
cares only about root command).
It might be very easy to forget adding that if new command creation is not automated and there are many commands added by multiple people, potentially by multiple teams. |
Think this was fixed by #2044 and released in 1.8.0 |
Great news! I think it's worth closing all issues and non-merged PRs now 🎉 |
PersistentPreRun and PersistentPostRun are chained together so that
each child PersistentPreRun is ran, and the PersistentPostRun are ran
in reverse order. For example:
Commands: root -> subcommand-a -> subcommand-b
root - PersistentPreRun
subcommand-a - PersistentPreRun
subcommand-b - PersistentPreRun
subcommand-b - Run
subcommand-b - PersistentPostRun
subcommand-a - PersistentPostRun
root - PersistentPostRun
fixes #252