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

More powerful options #129

Open
4 tasks
noraj opened this issue Jul 20, 2023 · 2 comments
Open
4 tasks

More powerful options #129

noraj opened this issue Jul 20, 2023 · 2 comments

Comments

@noraj
Copy link
Contributor

noraj commented Jul 20, 2023

Flags

options are always considered having a value --mode=http2 or --mode http2.

  • Having flags (options without value)

E.g. just having --color, having the flag equals options.fetch(:color) returning true, not having the flag equals options.fetch(:color) returning false. It's better than having --color true and --color false with values: %w[true false] and casting the string to a boolean.

Aliases

It would be nice to have has many aliases as we want for an option.

  • Having aliases

E.g. -c, --color or --color, --colour.

It's often handy to have long flags that are mnemotechnic and short flags for those familiar with the tool that want to type faster.

Mutually exclusive

Sometimes it is required to have mutually exclusive options, see #128.

Casting type

As passed from the CLI, all values are strings, so it would be handy to have cast types for options.

  • Having cast types

E.g. --age 21 or --advanced true. It's allows to cast type in the definition of the option, avoiding forgetting to cast it when the value is retrieved or to cast it several times if the option is used at multiple places.

@MadBomber
Copy link

MadBomber commented Oct 30, 2023

I think a few of these have already been put in place. For example I'm using ...

option :debug,
  aliases:  %w[ -d --debug],
  type:  :boolean,
  default:  false

amd the same structure for verbose in a Base command which defines all blobal options for all toerh commands.

edited ... I when back and looked at my code where I am using a type: :integer and darn it, the value is coming in as a string not the Integer that I was expecting. It was very clear when I setup a values: )0..255).to_a element in the option. My cli failed but did not tell me why.

@MadBomber
Copy link

MadBomber commented Oct 30, 2023

One of the things that I found myself wishing for is some kind of action that gets executed when the option is present. As is, those kinds of things have to be build as a command. I'd much rather put a simple Proc or Lambda in the option definition that have to layout a small command class. For example consider a version option.

option :version,
  aliases:  %w[ --version ],
  action: -> { puts VERSION; exit(0) }

... of course you'd going to ask where does that version constant come from? I'm assuming it comes from the command class. If I wanted it to come from the ProgramName I would have coded it with that name space.

As is, I had to create a Version command class and then for all my commands which have versions I had to register both the command and the command with a version sub-command.

register "my_command", self
register "my_command version', Command::PrintVersion.new(VERSION), aliases: %w[-v --version]

I've been experimenting in https://github.com/MadBomber/experiments/tree/master/cli_options/dry-cli

I have a monkey-patch in that repo that implements global_header, global_footer, header and footer to wrap the existing help text is what I want... like copyrights, contact info, etc.

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

No branches or pull requests

2 participants