smart completion in kubernetes to handle [[name = "something"]] for containers, volumes, env vars etc

[jstrachan]

I love the pkl intellij plugin and it makes overriding kubernetes yaml structures super easy! There's one thing I'd really love though as a developer UX thing

imagine we are editing this template; its a kubernetes Deployment and the cursor is inside the containers {...} block:

amends "..."

deployment {
  spec {
    template {
      spec {
        containers {

        }
      }
    }
  }
}

what I'd love is the top 3 completions to be

• new (its currently quite far down the list)
• [...] (for index based override)
• [[name = "..."]] which if you select the latter gives:

amends "..."

deployment {
  spec {
    template {
      spec {
        containers {
          [[name == "<cursor here>"]]  {
          }
        }
      }
    }
  }
}

FWIW the [[name == "..."]] completion should only appear if the type (in this case PodSpec.Container) has a name property.

I guess this is very kubernetes specific but its very common to want to override things in a Listing<T> by name in kubernetes.

e.g. customising any Deployment / Job / StatefulSet / Pod you usually want to configure a container / env var / volume and they all need to be done using the [[name == "..."]] syntax. Users should need to decide if they want a new or amend an existing item.

BTW it would be totally awesome if the plugin could grok what name values exist already in the parent template then smart completion could let you complete the string value on the right hand side of the "==" expression - so that you can only pick valid names :). Though thats probably much harder to do

[holzensp]

This seems a reasonable (doable, sufficiently general) ask. It's not Kubernetes specific at all for member predicates to be part of suggestions inside Listings and Mappings. I think we can generally improve the use of == by using type information there (which we currently don't). It's finicky, though, because types of the operands of == only need to overlap (not be contained).

Evaluating upstream values is very quickly prohibitive perf-wise. We only do very limited evaluation in the plugin, because there's no telling how much time the plugin will need (and it needs to remain responsive).