Golang Plugins for kube-linter about kube-linter

[janisz]

Looks like golang supports plugin loading through https://pkg.go.dev/plugin.

I think this is halfly baked feature :(
We are thinking about having a way to declare CRDs maybe this could be done in some kind of scripting language #24

[Voldemat]

Why do you think so? I`m just curious, as don`t program in Go a lot, mostly Python and Typescript. On first glance sounds like a cool feature. For example we can define each custom linting rule as separate file, then compile it in docker build and load it in runtime when we call kube-linter.

[janisz]

Why do you think so?

Good question so I've asked chat gpt about it 😄

• Limited platform support: Go plugins were primarily designed for Unix-like operating systems. They were not well-supported on all platforms, which limited their portability.
• Limited dynamic loading: Go plugins were capable of dynamic loading and unloading, but the implementation was not as flexible as some other languages. Loading and unloading plugins could be tricky and had some restrictions.
• Limited access to symbols: Plugins in Go had limitations in terms of accessing symbols (functions and variables) defined in the host program. This was due to concerns about maintaining type safety and avoiding symbol conflicts.
• Compatibility issues: Plugins were sensitive to changes in the host program's code. If the host program was updated or recompiled, it could lead to incompatibility issues with existing plugins.
• Lack of official support: While Go plugins existed, they were not part of the official Go standard library, indicating that they were not fully matured or recommended for production use.

---

In my experience although they look like java jars or dynamic libs they are not close to this. Another thing is popularity, I've not seen many projects using it (although there are some. Even golangci/golangci-lint which could be perfect case for a plugin system is based on including a linters and compile them all into a single binary and other projects prefer subprocesses or some other solutions like traefik/yaegi or hashicorp/go-plugin

Other sources:

@mvdan: Because I think the Plugin package is a very good idea, but it's sort of half-baked. It has no Windows support, it's very easy to misuse... If somebody else builds a plugin and tries to run it with your binary, it's almost certainly not gonna work. So I think it's a great idea, but it should never have hit the standard library until it was finished.

Don’t use Go’s plug-in system, it’s essentially a hacked together mess that really should be deprecated.

[Voldemat]

ChatGPT saver of all) Yeah it makes sense, subprocess approach would be much better, only thing that can go wrong is performance.

[AlanMasciangelo]

I'm also looking to extend with fully custom checks but based on the examples it looks like only way is to fork and rebuild, is this correct?