Upgrade to Cobra 1.0 #916
Upgrade to Cobra 1.0 #916
Conversation
|
It's nice that we can remove the fish hack, but the subcommand error issue seems like a step backwards. Would it be better to open an issue on Cobra and wait before upgrading?
I've been wondering about this too. Maybe a good hack day project? |
I don't think it would be wise to wait. There are probably at least two dozen issues in the cobra repository about this and people have attempted to fix it, but I think they were limited due to having to keep backwards compatibility (Cobra is a framework for a lot of apps). I'm much more in favor writing our own dispatcher, since our dispatching needs are very simple. |
|
I'm fine with writing our own dispatcher. Should that be a prerequisite for the cobra 1.0 upgrade, though? |
Not necessarily! I think it's acceptable for now to have |
|
I'm worried about losing the "did you mean..." functionality until we get our own dispatcher written (which is work that is unscoped and doesn't even have an issue yet). It's small but I think goes a long way when people are trying to learn our tool. Getting rid of the fish hack is 👍 but really doesn't seem worth the trade of the error handling to me; after thinking about it more I'd rather the new dispatcher be a requirement for this. I am absolutely in favor of writing our own dispatcher because it would help with error handling as well as things like controlling help output more finely, expanding aliases, and potentially testing. Unfortunately I don't feel like I have a good grasp on the amount of effort and time involved; do you, @mislav ? |
Note that we never did have "did you mean" for subcommands, only for top-level commands. To illustrate, the current behavior is: $ gh issue listt
#=> output of `gh help issue` printed to stdout
#=> "subcommand is required" printed to stderr
#=> exit code: 1At first I thought that writing a dispatcher that only covers our own needs would be easy, but now I'm finding that it would not be so straighforward due to addition of advanced shell completion support in Cobra 1.0 injected via hidden command. Currently it's behind private methods, so if we wanted to port that over to our own dispatcher, we would have to copy-paste some implementation, and then we're basically back to square one like we were with fish completion before. I think we could do better by overriding |
…ands
When executing `gh pr re` (note the incomplete command name), Cobra
would just display the help text for `gh pr` on standard output, exit
with status 0, and not print any message that you have mistyped the
"re" subcommand. Each part of this behavior is wrong.
This workaround makes sure that the helpful error message is printed on
stderr:
$ gh pr re
unknown command "re" for "gh pr"
Did you mean this?
reopen
ready
review
However, the exit status is still 0, whereas it should be non-zero.
Since `HelpFunc` does not return an error argument, we cannot trigger an
error status from this workaround.
|
Okay, got something working: Success tally:
I'm feeling that we can ship like this. 🚀 |
The most gratifying result of the upgrade is that we get to remove our obsolete hack to generate fish completions.
The downside is that Cobra still hasn't figured out their error handling, and it looks like it's getting worse instead of better. How this issue affects us is this:
Compare that with this, which had always worked:
Cobra treats error handling in top-level commands differently than in sub-commands, but after digging a lot through Cobra I could not find ways to change this behavior. For example, I tried defining a custom
issueCmd.Argschecker, but sinceissueCmdisn't "runnable" (it doesn't have aRunfunc),Argsis downright ignored.This error handling issue is not necessarily a blocker, but at this point I'm thinking that it would be easier to write our own command dispacher instead of relying on Cobra's buggy one.