Question: new plugin and conflicting plugin name
patrickdappollonio opened this issue · 8 comments
Hello Krew maintainers!
Recently I launched kubectl-split and it was well-received. I got the inspiration after trying to look for a tool that can do that and finding @brendanjryan's k8split. Unfortunately, the inability of being able to change the file name for its output was quite limiting. That, and the fact that the original YAML comments were lost -- and some of the ways people might prefer to keep their YAML arrays might be different than what the re-encoding of the YAML would render. So like the XKCD says, I wrote my own 😅
After sharing it in a couple of places, I got in contact with some folks to try and get it into krew and to my surprise, there's already another tool that performs the basics with an opinionated format of doing so.
He suggested I should still create an issue, I'm looking for feedback on how to address this, whether the application should not be in krew or if it should, but renamed -- and some people rightfully so said that it might be rejected just because they're quite similar in behavior. I'm happy to rename it in any way and it's a useful tool to me as is, which was the original intention.
I have an open roadmap of potential useful quality-of-life features that I want to see in the tool (nothing too crazy) as well as some documented differences when comparing against other tools which might help answer the questions on how "different" is this app compared to k8split and even potentially against kubectl-split-yaml.
Looking forward to your feedback!
/cc @corneliusweig
/cc @chriskim06
/kind gray-area
I think this is a unique case we have not encountered before. There's already a plugin split-yaml that does 90% of the job, although the proposed plugin here (https://github.com/patrickdappollonio/kubectl-split/) is more polished and feature-rich.
We've historically rejected plugins because a very similar alternative already exists, but that prevents innovation in the space. On the flip side, we recently accepted lineage plugin, because it's a better alternative to tree plugin.
Wanted to open this up to discussion about how we approach these situations.
We've historically rejected plugins because a very similar alternative already exists, but that prevents innovation in the space.
I'm personally pro-opening the index to plugins that have similar functionality to existing plugins for that reason you mentioned. I still think it's a good idea to reject plugin submissions that are fully covered by existing ones.
I think the tricky part would be defining what constitutes new/different functionality and balancing that with potentially opening ourselves up to getting a bunch more plugin submissions. If we allow this, maybe we would start getting a lot more plugins which might not have been submitted if the author saw that their's was already too similar to an existing one. Although we currently get those already so maybe this isn't too much of a concern.
I saw there was some work being done to refine some of the criteria to accept or reject plugins, by @corneliusweig on #152 which is nice to see, but unfortunately, it seems to be stuck in a bit of a limbo since 2019.
As a general proposal too, I think this should also account for any possible abandonware -- not that any of the competing projects mentioned before have a glimpse of being abandoned, but it might happen: a developer might also go on their merry way and potentially forget, especially if they're not active on Github, that their plugin might need an update (for example, CVEs or just kubectl moved forward so compatibility can't be guaranteed).
On the more personal side, @chriskim06 if you have any pointers whether in terms of naming or direction, happy to hear them!
Other terms that came to mind are deconstruct, extract.
Appreciate the name ideas @ahmetb! I think extract-yaml might work just feel a little odd. It could be misunderstood as "send me a Markdown file that might contain YAML and the tool will work with it". deconstruct might be better but still feel long to type.
After some folks saw this issue, they reached out to me, two made a great proposal for a name which I think it's quite close in meaning and feel: "slice".
We might stick to it, the question would be if you guys would prefer slice-yaml or is slice good enough (considering some previous plugins have been requested to be renamed; however, "slice" alone where the input is already understood to be YAML might be enough imho).
On another thought, I read the naming conventions and one of the things that might be unclear is if good names can be "fictional" names. For example, is it good if a plugin has a name that follows the "sea", "ship", "container" pattern?
@ahmetb @chriskim06 @corneliusweig is it okay if we start a Pull Request with slice (or if you would rather see it as slice-yaml)?
@patrickdappollonio SGTM.
/close
@ahmetb: Closing this issue.
In response to this:
/close
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.