Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

poy
Copy link

@poy poy commented Oct 14, 2020

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

@CLAassistant
Copy link

CLAassistant commented Oct 14, 2020

CLA assistant check
All committers have signed the CLA.

@poy poy force-pushed the change-persistent branch from baf1dd8 to 22954be Compare October 14, 2020 04:52
@marckhouzam
Copy link
Collaborator

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).

@poy poy force-pushed the change-persistent branch 2 times, most recently from 955c56c to a51d94f Compare October 14, 2020 12:10
@poy
Copy link
Author

poy commented Oct 14, 2020

This PR will allow a user to create a hierarchy of PrePersistentRun and PostPersistentRun. Meaning if the root and sub command both have a hook, then both will be invoked. The pre-hooks get invoked in order of root -> subcommand-1 -> subcommand-2 -> ... -> subcommand-N. This allows the earlier subcommands to setup anything necessary for the laster commands. The post-hooks are invoked in the opposite order: subcommand-N -> ... -> subcommand-2 -> subcommand-1 -> root. This reverse order allows for easier cleanup (similar to how defer was implemented).

This is not a breaking change (now :) as this behavior only takes place when TraverseChildrenHooks is set to true on the root node. It will otherwise utilize the old behavior of subcommands overriding their parent's hooks.

@poy poy force-pushed the change-persistent branch from a51d94f to f82d6f2 Compare October 14, 2020 12:28
@poy
Copy link
Author

poy commented Dec 4, 2020

Is there any chance of this being merged?

@infalmo
Copy link

infalmo commented Dec 11, 2020

@marckhouzam A gentle reminder to review (and merge) this PR when free 😄

@marckhouzam
Copy link
Collaborator

@marckhouzam A gentle reminder to review (and merge) this PR when free 😄

I'm not a maintainer 😉
I just try to help when I can.

@marckhouzam
Copy link
Collaborator

This PR will allow a user to create a hierarchy of PrePersistentRun and PostPersistentRun.

@poy Could you instead call cmd.Parent().PrePersistentRun() from the subcommand?

@poy
Copy link
Author

poy commented Dec 14, 2020

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.

@github-actions
Copy link

This PR is being marked as stale due to a long period of inactivity

@poy poy force-pushed the change-persistent branch from f82d6f2 to b528b57 Compare June 2, 2021 03:33
@poy
Copy link
Author

poy commented Jun 2, 2021

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
@f0m41h4u7
Copy link

Hey all.
I am also facing this issue with persistent pre- and post-runs currently, and it leads to some annoying code repeats... So I'm really looking forward to this fix being merged some day.

@niamster
Copy link
Contributor

niamster commented Nov 4, 2023

@marckhouzam A gentle reminder to review (and merge) this PR when free 😄

I'm not a maintainer 😉 I just try to help when I can.

@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
Copy link
Contributor

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
Copy link
Contributor

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).

@niamster
Copy link
Contributor

niamster commented Nov 4, 2023

This PR will allow a user to create a hierarchy of PrePersistentRun and PostPersistentRun.

@poy Could you instead call cmd.Parent().PrePersistentRun() from the subcommand?

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.

@polothy
Copy link

polothy commented Nov 6, 2023

Think this was fixed by #2044 and released in 1.8.0

@niamster
Copy link
Contributor

niamster commented Nov 6, 2023

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 🎉

@marckhouzam
Copy link
Collaborator

Thank you for your efforts @niamster . I'm going to close this as #2044 addresses this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PersistentPreRun only allowed once
7 participants