-
Notifications
You must be signed in to change notification settings - Fork 476
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
added plugin pod-inspect #1021
added plugin pod-inspect #1021
Conversation
/assign @chriskim06 |
/hold |
@ahmetb - I'm not sure what I did wrong here. Yes, I removed the template, but that appeared to be a comment that doesn't need to stay in the request once it's filed. I did read the naming guidelines. Did I violate the guidelines? I've already had to rename my plugin twice to try to get something that works with kubectl and that (I thought) met the guidelines. |
https://krew.sigs.k8s.io/docs/developer-guide/develop/naming-guide/ |
When I first read the naming guidelines, I was still planning to use "pod-inspect". I then tried "pod-inspect", and it didn't work (I put kubectl-pod-inspect in my path, but kubectl wouldn't recognize it), so I renamed it "pod_inspect", forgetting item #1 in the naming guidelines. My apologies. I understand that krew does some symlink magic, but if I use kebab-case, then my plugin won't work outside of a krew context (without asking my users to do some extra work to rename the executable or symlink it or whatever). Do you have any guidance so that a developer can build a pluging that easily works both inside and outside of krew? |
You can leave the binary name snake cased, it's just the plugin name should be kebab cased. There's a few plugins like this, cert-manager is one that I can immediately think of. |
@chriskim06 - great idea. I'm refactoring now. One thing I noticed: the go snippet to detect whether running as a plugin on this page: https://krew.sigs.k8s.io/docs/developer-guide/develop/best-practices/ doesn't seem to actually do anything different when the command is run directly vs as a plugin. I'd really like to detect that so that I can output appropriate usage for the person who happens to run my plugin directly. I find for kubectl plugin beginners, this dichotomy is kind of confusing. Especially with the "-"/"_" naming issues. If you've got any other techniques for accurately detecting |
hmm I'm not sure, afaik none of our plugins do this currently. I would think most people would invoke your plugin via kubectl, so it wouldn't be an issue. |
If you install your plugin with Krew, that snippet will contain the name of the symlink (kubectl-foo_bar) we create for your plugin in os.Args[0]. So if you distribute your binary without kubectl- prefix, you can easily tell the difference. Does that help? |
Updated pull request with renamed plugin. I found a couple of thing:
|
@ahmetb - that's an option I didn't think about - I was fixated on calling my binary "kubectl-SOMETHING". I don't think it's terrible the way I've structured it, but maybe at some point in the future, I'll change the binary name so I can tell the difference. I've spent WAY too much time refactoring this thing, and I'm not inclined to change anything needlessly at this point. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahmetb, jpriebe The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This looks like a fine plugin! Thanks for building and sharing! 🎉 |
No description provided.