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

Feature request: Support subcommands with arguments #1

Closed
ndmeiri opened this issue Apr 11, 2020 · 3 comments
Closed

Feature request: Support subcommands with arguments #1

ndmeiri opened this issue Apr 11, 2020 · 3 comments

Comments

@ndmeiri
Copy link

ndmeiri commented Apr 11, 2020

Currently,

command = Lino::CommandLineBuilder
    .for_command('x')
    .with_subcommand('y') do |sub|
      sub.with_argument('fake_argument')
    end

results in

undefined method `with_argument' for #<Lino::SubcommandBuilder:0x00007f8b8289b268> (NoMethodError)

Would it be possible to add support for with_argument in SubcommandBuilder?

@ndmeiri
Copy link
Author

ndmeiri commented Apr 11, 2020

I suppose with_argument('fake_argument') could be called outside of (i.e., after) the subcommand configuration block, but there could still be use cases where the subcommand's argument needs to come before the subcommand's options.

@tobyclemson
Copy link
Member

Hi Naji,

Thanks for raising the issue. I have a few questions on what you'd expect here. Let's say a command uses a structure that has sub and sub-sub commands:

command = Lino::CommandLineBuilder
    .for_command('x')
    .with_subcommand('y')
    .with_subcommand('z')

Today this produces x y z. Now, let's say we allow each of those to have arguments:

command = Lino::CommandLineBuilder
    .for_command('x')
    .with_subcommand('y') do |y|
      y.with_argument('a')
    end
    .with_subcommand('z') do |z|
      z.with_argument('b')
    end

What would you expect the command to end up as? x y a z b?

There's then a risk of misinterpreting arguments as subcommands and vice versa. It's for this reason that most commands expect or at least allow all arguments to come last after flags and options. And it's based on this that arguments is considered a top level method rather than a subcommand method.

Let me know your thoughts,

Thanks,
Toby

@ndmeiri
Copy link
Author

ndmeiri commented Apr 12, 2020

Hi Toby,

Thanks for the prompt reply! That's fair; I hadn't considered that ambiguity.

FWIW, I would expect x y a z b. I would expect that the command (y in this case) would correctly interpret a as an argument if y was indeed expecting it. If y was not expecting argument a and so misinterpreted a as an (invalid) subcommand, I would expect y to emit some error and halt. i.e., I consider it the user's responsibility to build a well-formed command for their use case.

But I do see the drawbacks, and the command I'm trying to use does indeed allow arguments to come last, so I'll close this out!

Thanks!

@ndmeiri ndmeiri closed this as completed Apr 12, 2020
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