community

I think what Charts v3 will be is still an open question. According to the current accepted HIPs[0], there is some groundwork to in general enable a new generation of a chart format via HIP-0020, and most HIPs after that contain some parts that are planned to make it into Charts v3 (e.g. resource creation sequencing via HIP-0025). [0]: https://github.com/helm/community/tree/main/hips

On top of what the OP mentions, Helm still doesn't have a way to forward logs from its pre/post-install hooks to the system calling helm upgrade (such as a Github Action) - a feature first requested in 2017 and still stuck in RFC stage. https://github.com/helm/helm/issues/2298 https://github.com/helm/helm/pull/10309 https://github.com/helm/community/pull/301 I can understand moving cautiously, but it's at a point where it almost feels like allowing users to understand what Helm is doing seems not to be a priority for Helm's developers.

> But say we went with that. Then we'd need to adopt an existing JS engine (most likely written in C++) and then modify it based on our needs. This is definitely not an easy choice to make and writing a new language interpreter in Go seems a way easier approach initially. One thing that Go helped me to understand though, is that the language does not matter so much as the tooling around it - debugging, compiling and support around the language are way harder to achieve than writing a language parser. Thanks for sharing your thoughts on this design choice, I think this discussion is very relevant for a couple of reasons: There are other Go projects that are taking the same approach to achieve simplicity and not picking the existing language, like OPA [1]. Others, like Helm are picking Lua [2], so there is clearly a problem the Go and infra

The helm 3 proposal uses Lua. Not sure if they've actually started working on it: https://github.com/kubernetes-helm/community/blob/master/hel...

Have you taken a look at some of the Helm 3 proposals? One of the points that talks about this exact use case is the concept of a "library chart", which is a way to define a block of code once and import it into another chart. In your case you could then define a block of code which will spit out a set of kubernetes labels that is shared across all your charts. https://github.com/kubernetes-helm/community/blob/master/hel... Your other point about it being difficult to interact with the kubernetes and Tiller APIs in any other language than Go is true, though it isn't necessarily a Helm Thing. This is a Kubernetes Thing. Tiller's going away in Helm 3 so the side effect should be that Helm will be much simpler to extend.

Helm Version 3 will adopt CRDs for release and application state. There will no longer be a server side component (tiller). It should be much easier to integrate other tools or templating systems with V3. https://github.com/kubernetes-helm/community/blob/master/hel...