Is there an effective way to modify the contents of a listing?

[MarkSRobinson]

I'm working with the k8s objects in pkl and one of the major concepts in k8s is that objects are pretty deeply nested with lists.

For example, this piece of pkl will generate a Service object with a single port object

services {
  ["release-name-"+name] {
    spec {
      type = "ClusterIP"
      ports {
        new {
          port = 80
          targetPort = "http"
          protocol = "TCP"
          name = "http"
        }
      }
    }
  }
}

and the yaml it generate is pretty simple

apiVersion: v1
kind: Service
metadata: {}
spec:
  ports:
  - protocol: TCP
    port: 80
    name: http
    targetPort: http
  type: ClusterIP

What I'm trying to figure out is what is the best way to support changing some of these deeply nested items. For example, say I want to change the listening port. The only things I've found I could do this is either (a) pull the Service.ServicePort item out into a separate object that I can alter in a downstream module, or (b) just flat out override the ports item entirely and start from scratch. I can't seem to alter list items in place at all.

Ideally, I'm trying to get a place where I can specify reasonable defaults but make it reasonably easy for someone to override them as needed. The common pattern in helm is to rip out every variable into a values file and let people dig around with it.

[translatenix]

One way to modify the listing element is ports { [[name == "http"]] { port = 99 } }.

[holzensp]

@translatenix is using a member predicate there. If you know the element by index, you can also ports { [0] { port = 99 } }, which amends the element at index 0. If you're actually defining things according to a (somewhat) standardised layout where elements of that layout can be given meaningful names, you can define

standardClusterPort: Service.ServicePort = new {
  port = 80
  targetPort = "http"
  protocol = "TCP"
  name = "http"
}

and define your services as

services {
  ["release-name-"+name] {
    spec {
      type = "ClusterIP"
      ports {
        standardClusterPort
      }
    }
  }
}

Now, users of your template can amend the top-level standardClusterPort instead of having to dive in.