-
-
Notifications
You must be signed in to change notification settings - Fork 141
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
Unable to fully capture the rest of arguments and pass it through to another command #253
Comments
My guess is |
I think the issue is in order of processing tokens, |
I think that allowing |
I think there are two use cases and both seem valid:
|
Allowing |
After more thought, I realized two things. First, the problem is larger than I thought. Running The other is that I think the core of the issue is in flags being inherited from the parent. This is why it is surprising that So I think the solution here is to do:
Bonus question: how should |
The problem with allowing only flags under a command to be parsed, then passing anything else on, is that if you add more flags to the command in the future you may break previously working commands. For example, say the first version of the command had one flag
If you subsequently add a I feel like the cleanest option is your initial suggestion of supporting eg. Cmd struct {
Args []string `arg:""` // <- required and only field allowed
} `cmd:"" passthrough:""` |
Sure, but doesn't this hold also if I pass everything on after What I am trying to say is that the mechanism how we describe in the configuration of CLI parsing to pass things on to a sub-tool does not prevent breakage by itself. As a developer managing this configuration I can always introduce changes which break previously working commands. I think this can be addressed only by documenting properties and gotchas of the configuration so that developer can choose the right modification and know what are the consequences. E.g., if we add But if you prefer to go this route, I would add that I find configuration which forces the structure a bit ugly (i.e., a bit forced and not nicely orthogonal). Why do I even need nested struct at that point? Like, why not have: Cmd []string `cmd:"" passthrough:""` |
Yes but that's explicit, whereas the other behaviour is indirectly implicit and not at all obvious until it bites you.
Because this is inconsistent with the rest of Kong and additionally it wouldn't directly work with |
Hm, what about: type Args []string
Cmd Args `cmd:"" passthrough:""` That works with |
(FYI, it is your package, so feel free to just make a decision here. I am suggesting alternatives because I am trying to see if we can find a better design here, but if you feel we already reached it, just say so.) |
I've already stated my position after quite a bit of back and forth, so I saw no need to continue discussing it further. It is: Cmd struct {
Args []string `arg:""` // <- required and only field allowed
} `cmd:"" passthrough:""` But regarding also allowing flags, I think it would be sufficient to have an explicit whitelist in this situation, with an error if a flags is added without also being in the whitelist. eg. Cmd struct {
Flag1 string
Flag2 bool // Kong will error on this flag
Args []string `arg:""` // <- required and only field allowed
} `cmd:"" passthrough:"" allow-flags:"flag1"` |
Sounds good. I will see if I can get to this any time soon and make a PR. I do not get why we would need |
I made #262. |
Because it's explicit, and because it will work correctly for flags on parent commands. But yeah we can worry about this later. Your PR is a great start, thank you. |
I see. Thanks for the explanation. |
Great stuff, thanks again. Let me tag a new release with this in it. |
So I am trying to implement
exec
pattern, where I have a subtool I want to execute and pass all other arguments to it. Tryingpassthrough:""
does not fully work with--help
flag. I have something like:Inside
ExecCommand
'sRun
I do:subtool.Main(append([]string{"subtool"}, c.Arg...))
to pass all args to thesubtool
's CLI parsing.And this does not work. So if I do:
it works well, and sub-tool gets
foobar
as an argument.But:
returns help of
tool
and not of the sub-tool.A workaround is:
which does work. But how can I make it work without
--
? I think this might be related to #216 and in general that I would prefer that global flags do not get inherited by the subcommands. So in generaltool --help subcommand
should work andtool subcommand --help
should not, unless subcommand explicitly defines--help
flag.I tried to move
passthrough:""
toExec
itself, but I got panicpassthrough only makes sense for positional arguments
.The text was updated successfully, but these errors were encountered: