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

set debug true doesn't propogate #4

Open
leith-bartrich opened this issue Oct 17, 2018 · 5 comments
Open

set debug true doesn't propogate #4

leith-bartrich opened this issue Oct 17, 2018 · 5 comments
Labels
question Further information is requested

Comments

@leith-bartrich
Copy link

In previous versions of submenu (that were part of the cmd2 module) a submenu would use its parent's "debug" variable. Such that when I ran "set debug true" and then encountered an error in a subsequent command within a submenu, the "debug" flag was respected and I would get a stack trace. The version currently in the fix_bugs branch, doesn't exhibit that behavior. Instead, I need to enter the subcommand by calling it with no arguments. Then, I can "set debug true". And then I get the expected (legacy) behavior.

@tleonhardt tleonhardt added bug Something isn't working question Further information is requested labels Oct 17, 2018
@leith-bartrich
Copy link
Author

Worth noting. I can fix this myself by adding "debug:debug" to the 'shared_attributes' and I get back the old behavior. I guess the question is which behavior is correct? I could see an argument being made that I should have to specify the debug attribute be shared explicitly.

@tleonhardt tleonhardt removed the bug Something isn't working label Oct 17, 2018
@tleonhardt
Copy link
Member

@kotfu @kmvanbrunt Do either of you have an opinion on how we should handle the debug runtime-settable parameter in the context of submenus? Should a submenu automatically inherit its parents debug setting? Or should that be something an individual developer needs to manually specify in their application?

@leith-bartrich
Copy link
Author

One other observation.

From a user perspective: the message that gets printed is wrong/unhelpful. It says you should run "set debug true" to get a stack trace. But of course, that doesn't actually work because it's a submenu command. The debug variable they are setting when they follow the advice, isn't the one for the cmd2 they are running. The user would need to implicitly understand that the command they are running is actually a whole other cmd with its own separate debug variable, to know why following the simple advice of running "set debug true" doesn't work in that case.

Which then begs the question: in that case, should the advice/error message change when running a submenu, to make it clear they'd need to enter the submenu first? Or should the debug propagate to avoid this special attribute problem?

@tleonhardt
Copy link
Member

@leith-bartrich I would encourage you to submit a PR to the cmd2-submenu repo that makes whatever changes you think would make the most sense from a user perspective and we can take a look at it.

@AHSauge
Copy link

AHSauge commented Jul 30, 2019

Maybe it's just me or my setup, but this seems extra broken now. If I type "set debug true" on top level, that works just fine. As we have established already, it still doesn't propagate. However, going to a sub level and typing "set debug true", I still don't get the stack trace I'm expecting.
(Need to create a more easily demonstrable case before I provide more on this)

In any case, the current message tells me to type "set debug true" regardless of where I am. At least from my standpoint I would have expected this to propagate to all levels, and I'm not sure how easy it is to grasp that this is applying to only the current level one is at. The message would at least have to specify the level at which it needs to be applied, otherwise getting the message after running "second third foobar_cmd" could be a bit confusing. For that reason, I'm guessing the easiest route would be to just propagate it all the way from top to bottom.

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

No branches or pull requests

3 participants