Krew bash completion do not work on 0.4.3

[wallsfantasy]

After I installed krew 0.4.3 I got a symlink in my local .krew/bin directory

~/.krew/bin/kubectl-krew

However, krew bash completion do not work unless I change the file name to krew.

~/.krew/bin/krew

But then kubectl will not recognize kubectl krew.

My workaround is to create symlink krew pointing to the original one.

~/.krew/bin/krew -> ./kubectl-krew
~/.krew/bin/kubectl-krew -> ~/.krew/store/krew/v0.4.3/krew

[ahmetb]

Hmm I don't think we actually have shell completion. I wonder if something new is using a hidden completion system our CLI library has.

How did you install? Which platform/distro? Can you find the completion file by any chance?

I have never seen krew complete anything. So I am surprised.

[wallsfantasy]

Hi, I'm on ubuntu 22.04 desktop.

While I'm exploring krew I tried kubectl krew --help and there's completion like this..

Usage:
  kubectl krew [command]

Available Commands:
  completion  generate the autocompletion script for the specified shell
  ...

So I generated bash completion and put the in bash_completion.d, like I normally would..

kubectl krew completion bash | sudo tee /etc/bash_completion.d/krew > /dev/null
source ~/.bashrc

I'd guess some of your lib might generate it for you. But it quite nice at least I can't remember commands of every tools I'm working with :)

[ahmetb]

Oh, I see. You are install it yourself.

I don't think we tested this. I guess the answer depends on the completion system but maybe there's a name you can give to the file make the completion work.

Or maybe it's because "krew" is hardcoded in the comp file.

Either way, it's currently an unsupported use case. The shell completions for plugins is still being figured out in kubectl upstream.

[chriskim06]

should we disable this cobra feature? the completion file it generates has

if [[ $(type -t compopt) = "builtin" ]]; then
    complete -o default -F __start_krew krew
else
    complete -o default -o nospace -F __start_krew krew
fi

if we want to disable it we just need to add rootCmd.CompletionOptions.DisableDefaultCmd = true to here i think. it only provides completion for the immediate subcommands

$ krew [tab][tab]
completion  (generate the autocompletion script for the specified shell)  search      (Discover kubectl plugins)
help        (Help about any command)                                      uninstall   (Uninstall plugins)
index       (Manage custom plugin indexes)                                update      (Update the local copy of the plugin index)
info        (Show information about an available plugin)                  upgrade     (Upgrade installed plugins to newer versions)
install     (Install kubectl plugins)                                     version     (Show krew version and diagnostics)
list        (List installed kubectl plugins)

edit: actually we could potentially add completion for the various subcommands it seems https://github.com/spf13/cobra/blob/master/shell_completions.md#completion-of-nouns

[ahmetb]

Yeah, we can disable it. It could be useful for people who install directly via Homebrew (hence have krew binary directly) and Homebrew knows how to install completion scripts.

My experience in kubectx (I'm not even supporting the any linux officially) is that we get awful lot of confusion and issues stemming from people trying to install shell completion and running into issues. Based on my experience from there, there's no way to solve this cleanly across platforms×shells×distros×pkg managers and it's often a mess.

FWIW the builtin kubectl feature is being worked on here. https://github.com/kubernetes/kubernetes/issues/74178#issuecomment-1020523792

[chriskim06]

nice. ok so then if that proposal goes through for kubectl then we could provide a kubectl_complete-krew binary with krew to provide completion for krew commands? like kubectl krew install [tab][tab] lists plugin names

[ahmetb]

(We're going out of scope of the issue here but) my plan was that if that proposal goes through we offer options in the plugin manifest to developers how they want to integrate with this feature. For example, we can offer a symlink feature where we link kubectl_complete-krew to kubectl-krew, but in the program, we can look at os.Args[0] to determine if we should print the completion script and exit. Some other plugin may choose to distribute a comp file (or a different executable to print a comp file).

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.