-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
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. |
@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? |
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? |
@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. |
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. 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. |
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.
The text was updated successfully, but these errors were encountered: