-
Notifications
You must be signed in to change notification settings - Fork 937
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
[1.12] plugin commands with dashes cannot be invoked with their original names #540
Comments
/kind bug |
Hey @ahmetb thanks for pointing this out. $ cat /usr/local/bin/kubectl-dash_test
#!/bin/bash
echo "I am a plugin with a dash in my name"
I have a PR updating the website's plugin documentation here and will make sure to specifically mention this part of the design on there. Thanks |
@juanvallejo That sounds like good news! It's not a great hack but it seems like it can do the trick. I'll close this once I verify. |
/assign |
Thanks. To clarify, this does not prevent underscores from being used as part of a command's name, rather it means that plugin commands with underscores can be invoked either with an underscore or a dash:
|
@juanvallejo Yes, I see now. I think this gives us enough to refactor existing krew plugins to work. Thanks. |
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Kubernetes version (use
kubectl version
): 1.12.0-beta.2What happened:
There are already plugins named with dashes (
-
) in the plugin name, such as:open-svc
ca-cert
rm-standalone-pods
in the krew package manager. There are also many plugins outside krew, such as:
kubectl 1.12 splits the names of these plugins into separate subcommands, such as:
kubectl plugin open-svc
kubectl open svc [...]
kubectl plugin rm-standalone-pod
kubectl rm standalone pod [...]
What you expected to happen:
This new behavior is quite unexpected for me. This makes it:
impossible to write plugins with dashes in the name
For example, if I write a plugin named
port-forward-better
, my users have to invoke it askubectl port forward better
(not desirable) as opposed tokubectl port-forward-better
.Undesired categorization of plugins that share the same prefix:
For example, if I'm writing a plugin named
rm-standalone-pods
installing a plugin with anotherrm-
prefix (such asrm-completed-jobs
). They will be (someday) grouped underkubectl rm
despite they're different plugins.I Expected: if a plugin named
kubectl-delete-all
exists, I should be able to call itkubectl delete-all
. Being able to call it askubectl delete all
may still be ok as the artifact of the feature, but it should not preventkubectl delete-all
invocation.I am sorry I wasn't there to review the design but I think design won't work for the broader plugin ecosystem.
/cc @soltysh
/cc @lbb
The text was updated successfully, but these errors were encountered: