Closed nanobowers closed 4 months ago
Note that this implies that -h and -v for help/version are not automatically created when --help and --version are. I'm a little conflicted about this, as -h is very common for a help message but it feels inconsistent to not do so. the net result is explicit definition of opt :help in order to get both --help/-h. Feedback appreciated.
That is indeed tricky. I'd probably be ok with merging as is without that.
Spitballing an idea, I was thinking what if we had something to "edit" a previously defined opt? That way it wouldn't replace the opt, but would merge into it. Roughly:
opt_override :help, :short => "h"
This would also allow you to "plugin" things that could override or even remove options. In one of our gems, I provide helper methods for building CLIs with common options (for example, --dry-run, -n
), and it looks like:
opts = Options.options do
opt :foo
MultiRepo::CLI.common_options(self)
end
What I can't do is modify those options after they've been added - I would love to do something like:
opts = Options.options do
opt :foo
MultiRepo::CLI.common_options(self)
opt_override :dry_run, :default => true
end
Thoughts?
Spitballing an idea, I was thinking what if we had something to "edit" a previously defined opt? That way it wouldn't replace the opt, but would merge into it. Roughly:
opt_override :help, :short => "h"
This would also allow you to "plugin" things that could override or even remove options. In one of our gems, I provide helper methods for building CLIs with common options (for example,
--dry-run, -n
), and it looks like:opts = Options.options do opt :foo MultiRepo::CLI.common_options(self) end
What I can't do is modify those options after they've been added - I would love to do something like:
opts = Options.options do opt :foo MultiRepo::CLI.common_options(self) opt_override :dry_run, :default => true end
Thoughts?
This is a neat idea, but i'm not sure it can easily solve the problem with hacking the opts created for help/version since they're autovivified inside the parse
method. At least the way I envision your opt_override
working, it would effectively find and edit an opt
command that was already given inside the block. I think it could work if opt_override worked with a delayed evaluation, but that's a little harder to reason with.
opts created for help/version since they're autovivified inside the parse method
Oh I misread the code...I didn't realize the block was executed before the opt :help
line. Yeah, we'd have to rearrange that where the help and version happens first, but that will create other confusions. 😕
In Optimist short options are automatically created for any given long option. (e.g:
-f
for--file
) Once enough options exist you are likely to have short-option name collisions, whereby you may compete for the short-option, and optimist must choose a backup short-letter e.g.Optimist wont allow collisions and thus it will go through letters to try to find a different unused letter. In this case
-f
for--file
and-o
for--format
(because thef
was already used). Unfortunately this makes the order ofopt
important. If you do this:then in this case you get
-f
for--format
and-i
for--file
.Often second choice short-arguments are not really what you want - it's not memorable. Additionally re-ordering or re-grouping options changes the short letter which is undesirable for users. IME, people tend to use the shortest means of enabling the option available so they get upset when you change the short-opt even though it's usually not as stable.
This can be fixed by using the
short:
argument foropt
. To disable short options for anopt
you can useshort: :none
. I often find that for less commonly used arguments I prefer to make the user call out the long form. This means settingshort: :none
on a lot of options. I prefer to setshort:
on every option to some value, so that I can ensure stability.This PR allows you to disable the implicit short option generation for
opt
. You can use the settingexplicit_short_opts: true
and this will prevent the automatic creation of all short opts. Once this setting is applied, short opts can be enabled by explicitly addingshort: '<letter>'
to theopt
.Note that this implies that
-h
and-v
for help/version are not automatically created when--help
and--version
are. I'm a little conflicted about this, as-h
is very common for a help message but it feels inconsistent to not do so. the net result is explicit definition ofopt :help
in order to get both--help/-h
. Feedback appreciated.If you don't add the
explicit_short_opts: true
, the present behavior of Optimist is unchanged.@miq-bot enhancement @miq-bot add-reviewer @Fryguy