-
-
Notifications
You must be signed in to change notification settings - Fork 203
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
app: support flags/aliases given as (--long, -short) tuple #319
Conversation
ca39361
to
b58e007
Compare
+ Specify both short/long flags/aliases of a once. + Update print-flag logic to print both flags in one place. + Print flag-equivalence at the end, e.g.: "Equivalent to: [Spec.verbose=True, Foo.bar=2] + Use the same format for aliases (do not clutter 1st line). + Renamed build-in varname `help` --> `fhelp`. - Had to catch exceptions in print_XXX_help(), otherwise difficult to debug miss-configurations. + Added TCs for short/long flags & flag equivalance.
b58e007
to
0448f35
Compare
11f0049
to
8a90693
Compare
Now it is ready to merge.
|
This PR tries to maintain compatibility with existing behavior, and adds single letter flags/alias prefixed both with single( I would prefer a simplification using the standard convention where a single-letter flag/alias are added only once, with single-dash. |
9be8541
to
73e1250
Compare
73e1250
to
ea395a3
Compare
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 would prefer a simplification using the standard convention where a single-letter flag/alias are added only once, with single-dash.
What do you think?
If I were starting from scratch, I would agree, but for backward-compatibility I think it's not worth breaking things for a minuscule aesthetic improvement.
lines.extend(fhelp) | ||
lines.append(indent("Equivalent to: [%s]" % longname)) | ||
except Exception as ex: | ||
self.log.error('Failed collecting help-message for aias %r, due to: %s', |
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.
Why catch/log these errors. Shouldn't they be bugs that raise?
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.
While developing it, the stack-traces for such errors happened very early in the boot-strap process and it was extremely confusing for me to debug such issues (practically speaking); eventually I had to manually wrap the offending code in a try-catch every time to locate the problem; eventually, I left it there for others, as explained in the commit message.
You can try it yourself if you have some class without description
trait, or badly formed flag.
Maybe we can retrofit the error behavior to help developers.
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.
Raising a clearer error sounds great. But I still think it should be an error, not a message that allows the application to continue. If you add raise
below here, it should be fine.
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.
Then I will remove the exception-wrapper completely; the point was to be able to read the help-message and discover what config-property were missing - the log-error actually does not help either; practically it just tells you that something went wrong.
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.
Sorry, I will leave it because by catching exceptions, the log-message knows which property failed and it DOES help; it will just raise as you said.
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.
Now that I think of it, (-n, --n, --name) is the same as (-n, --name), because argparse already accepts --n if you specify -n.
Nope...it doesn't work! All TCs with --i
fail.
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.
Now that I think of it, (-n, --n, --name)
is the same as (-n, --name)
, because argparse already accepts --n
if you specify -n
.
@@ -381,7 +404,7 @@ def print_help(self, classes=False): | |||
self.print_options() | |||
|
|||
if classes: | |||
help_classes = self.classes | |||
help_classes = self._classes_in_config_sample() |
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.
Why is this not self.classes
?
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.
See #289 discussion, and my example just entered in #180, specifically the comment in classes
trait.
[edit] And read the docstring description of Application._classes_in_config_sample()
:
Yields only classes with own traits, and their subclasses.
Thus, produced sample config-file will contain all classes
on which a trait-value may be overridden:
- either on the class owning the trait,
- or on its subclasses, even if those subclasses do not define
any traits themselves.
The same should apply for cmd-line options.
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.
Makes sense, thanks.
+ After @minrk codereview: ipython#319 (review) + minor: Remove unused builtin varname `help`.
+ After @minrk codereview: ipython#319 (comment)
4a5bc60
to
0a13126
Compare
+ After @minrk codereview: ipython#319 (comment)
+ After @minrk codereview: ipython#319 (comment)
0a13126
to
d327731
Compare
This is adding four
|
+ Enhance checking TCs.
Thanks, the TC were not that accurate; fixed both. |
Note, this has been merged (probably on 4.3.1) bust is not mentioned in the Changelog. |
This is not in 4.3.1, only unreleased master (will be 5.0). |
--help-all
to print all relevant configurables, along with their relations #296: print all relevant (sub)classes in help-msg.An example of the new flags/aliases help message: