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

[kubectl-1.12] Allow dash in plugin names #59

Closed
ahmetb opened this issue Sep 26, 2018 · 0 comments
Closed

[kubectl-1.12] Allow dash in plugin names #59

ahmetb opened this issue Sep 26, 2018 · 0 comments

Comments

@ahmetb
Copy link
Member

ahmetb commented Sep 26, 2018

Any krew plugin named like a-b-c today is symlinked as kubectl-a-b-c.

This causes plugin to be invokable only through kubectl a b c and loses the dashes in the original name.

Per kubectl/#540, the new design allows underscores (_) to be treated as - at invocation-time. This means, if a symlink is linked as kubectl-a_b_c, it can be invoked as kubectl a-b-c as desired (and equivalent of pre-1.12 behavior).

Proposed solution

Just replace dashes (-) with underscores _. This way we don't have to replace plugin identifiers in manifest filenames or name: fields.

This way krew can hide this implementation detail behind the covers and not expose it to both plugin devs and plugin users.

Will submit a PR shortly.

ahmetb added a commit that referenced this issue Sep 26, 2018
For dashes to be preserved in a plugin's name, its executable name must convert
dashes to underscores.

For example a plugin named "foo-bar" would today be linked as:

    kubectl-foo-bar

therefore, it can only be invoked as:

    kubectl foo bar

However, linking the same plugin as:

    kubectl-foo_bar

allows plugin to be called as:

    kubectl foo-bar
    kubectl foo_bar

- convert OS detection pluginNameToBin() to explicit input for testability
- test pluginNameToBin().

Fixes #59.
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

1 participant