-
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
Issue #219: added PreRunChain and PostRunChain hooks #220
Conversation
PreRunChain functions run in the order of root to child. PostRunChain functions run in the order of child to root. The overall exection order for a command is PreRunChain PersistentPreRun PreRun Run PostRun PersistentPostRun PostRunChain The following gist describes the usage and functionality https://gist.github.com/algrebe/23cc8bf4739a129a6d0d
42f7c84
to
3dbb5be
Compare
ToDo: use this spf13/cobra#220
@algrebe thanks for your reply, I'm looking forward to seeing next news! |
I'm fine with the functionality in general. I'm a bit worried this is a bit of an overcomplicated solution, but I must admit I don't really understand the use cases that would require all of this. This totals up to 7 different Run actions per command. It seems like overkill. Not a criticism, but more of a request to help me understand why we need all of these. It seems like a simpler approach could exist that would give us all the functionality we need. |
@spf13 thanks for your reply
For me, I just need something that always runs - irrespective of whether the child has its own hooks or not. I had always assumed As for the usecase - this was the issue I was facing #219 ( setting log levels and profiler at the root, and stopping it at the root - where I have access to the object that starts it ) I have a suggestion, which may / may not be acceptable but just throwing it out here - |
Chain without persistent makes sense to me. Should the default behavior of pre and post just be behavior described as On Tue, Jan 12, 2016 at 2:02 PM Anthony notifications@github.com wrote:
|
Chain without persistent makes sense to me. Should the default behavior of pre and post just be behavior described as This is a change in the existing functionality though, so previous users will have to be aware that Pre and Post have changed right ? |
Let's have @eparis weigh in first.
|
I'll start with that fact that I think chaining makes more sense than what we have now. What we have now is copying the Flags()/PersistentFlags() where 'chaining' just doesn't make sense. We have what we have so I'm all over the place on what to do. Imagine I have a subcommand pre/post that is calling the parent command pre/post. With a change to make 'persistent' 'chained' my parent command is going to get called twice. Imagine the same case where the parent pre/post isn't called today and shouldn't be, now it will be and the user of cobra won't have a reasonable way to know of this change in behavior. 2.0 API should ONLY have chained.... |
I agree. There's a good solution here thought that doesn't break compatibility and doesn't introduce a more complicated mechanism. We add a flag to Cobra that defaults to the current behavior, but can be flipped to the chain behavior. Cobra 2.0 we keep the flag, but change the default. Cobra 3.0 we remove the flag. That way new implementations can immediately take advantage of this cleaner approach while existing implementations can have time to migrate. Does that make sense? I recognize it's a big change, but I'm super weary of adding complexity to the interface and would much prefer to refine and simplify what we have now instead. If we can do that without introducing breaking changes that I think it's a win/win. |
@spf13 +1 |
+1 |
@algrebe can you update the PR accordingly? I'd gladly merge. |
@spf13 yes, this sounds good. Just to confirm
I'm confused about the order: |
This commit adds flags for profiling with runtime/pprof to storage put: - --cpuprof-path: specify a path of CPU profiling result, if it is not empty, profiling is activated - --memprof-path: specify a path of heap profiling result, if it is not empty, profiling is activated Of course, the flags should be added to RootCmd ideally. However, adding common flags that shared by children command requires the ongoing PR: spf13/cobra#220 . Therefore this commit adds the flags to storage put only.
We don't need persistent anymore. Just chaining. With chaining it should cascade down from the root to the run of the
|
Also I don't know about However I'm not sure what behavior we should get if the var is set on the root command but not on the subcommand being executed... |
It should only be able to be set (or checked) on the root. It's effectively On Wed, Jan 13, 2016 at 8:53 AM Eric Paris notifications@github.com wrote:
|
Added the functionality for persistent functions to chain from root to child in the case of PersistentPreRun and from child to root in the case of PersistentPostRun. Added a global internal variable useChainHooks which decides whether to use chain feature, or use the previous logic of nearest defined ancestor. This variable useChainHooks is disabled by default in this commit. Developers importing the cobra package can enable it using the function EnableChainHooks() or disable it using DisableChainHooks(). However, these functions may be called only once externally, preferably in the init of the developers main program.
@spf13 Hey, I think I've got a neat solution based on all the feedback - here it is. |
This commit adds flags for profiling with runtime/pprof to storage put: - --cpuprof-path: specify a path of CPU profiling result, if it is not empty, profiling is activated - --memprof-path: specify a path of heap profiling result, if it is not empty, profiling is activated Of course, the flags should be added to RootCmd ideally. However, adding common flags that shared by children command requires the ongoing PR: spf13/cobra#220 . Therefore this commit adds the flags to storage put only.
This commit adds flags for profiling with runtime/pprof to storage put: - --cpuprofile: specify a path of CPU profiling result, if it is not empty, profiling is activated - --memprofile: specify a path of heap profiling result, if it is not empty, profiling is activated Of course, the flags should be added to RootCmd ideally. However, adding common flags that shared by children command requires the ongoing PR: spf13/cobra#220 . Therefore this commit adds the flags to storage put only.
This commit adds flags for profiling with runtime/pprof to storage put: - --cpuprofile: specify a path of CPU profiling result, if it is not empty, profiling is activated - --memprofile: specify a path of heap profiling result, if it is not empty, profiling is activated Of course, the flags should be added to RootCmd ideally. However, adding common flags that shared by children command requires the ongoing PR: spf13/cobra#220 . Therefore this commit adds the flags to storage put only.
@algrebe I think we can do this without the persistent funcs at all... or at least I can't think of why we would need them. Just Pre & Post with a toggle option to make them universally chain-able or not. Am I oversimplifying it? |
@spf13 I cant find a reason where someone would want a hybrid of both chaining and running a hook just for that command in the same setup, so simplifying it makes sense to me. |
We should talk to @eparis. I'm not sure how much this existing feature is |
PreRunChain functions run in the order of root to child.
PostRunChain functions run in the order of child to root.
The overall exection order for a command is
PreRunChain
PersistentPreRun
PreRun
Run
PostRun
PersistentPostRun
PostRunChain
The following gist describes the usage and functionality
https://gist.github.com/algrebe/23cc8bf4739a129a6d0d