kubecfg VS github-desktop

kubecfg does add some features, like https:// imports, oci:// imports (oci bundles in OCI registries, transitively bundling all imported files with jsonnet-deps).

But yes, I strive to keep the "one file, one target, import whatever you need but explicitly" as much as possible.

I'm pouring some more time into the project and trying to implement some ideas I had for a long time but never managed to get them out. For example "Flags From Files" (https://github.com/kubecfg/kubecfg/blob/flagspec/docs/rfcs/r...) or "Caching + optional vendoring of immutable external deps".

You shouldn't write those manifests by hand in any non-hobby project. https://github.com/kubecfg/kubecfg

Should kubecfg be used instead (having active development)?

We use kubecfg and it is what I would recommend to anyone looking to create a sustainable GitOps workflow at work.

Yes that's a common problem with config languages. They're torn between competing priorities:

1. Fast to parse with a small engine, good error messages, safe to evaluate.

2. Powerful, can express config with arbitrary logic.

In Conveyor we try an alternative approach. The config is HOCON, which is a superset of JSON syntax designed for human readability/writability/convenience first and foremost, so it's got a very nice and clean feel to it. You can see an example here:

https://github.com/hydraulic-software/github-desktop/blob/co...

It can be parsed with a normal-sized config library and the errors you get are reasonable.

But then what if you hit the limits of what it can express? We added support for "hashbang includes":

    include "#!script.js"