Transform "Kind: List" into a more idiomatic yaml

[PierreR]

Would it make sense to integrate a tool that would transform:

---
apiVersion: v1
items:
  - apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/display-name: cicd KB technical documentation site
        openshift.io/requester: cicd_cicd
      name: cicd-doc-dev
  - apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: cicd-doc-dev-quota
      namespace: cicd-doc-dev
    spec:
      hard:
        limits.cpu: '2'
        limits.memory: "2Gi"
        requests.cpu: '1'
        requests.memory: "1Gi"
kind: List

into the more idiomatic/readable yaml:

---
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/display-name: cicd KB technical documentation site
    openshift.io/requester: cicd_cicd
  name: cicd-doc-dev
---  
apiVersion: v1
kind: ResourceQuota
metadata:
  name: cicd-doc-dev-quota
  namespace: cicd-doc-dev
spec:
  hard:
    limits.cpu: '2'
    limits.memory: "2Gi"
    requests.cpu: '1'
    requests.memory: "1Gi"

I fear the solution described in https://github.com/dhall-lang/dhall-kubernetes#can-i-generate-a-yaml-file-with-many-objects-in-it works fine but does no provide a compelling solution. It might be something that prevent adoption.
What do you think ?

[Gabriella439]

@PierreR: I probably wouldn't implement this, for the following reasons:

• We'd have to implement a new executable just to support this, which would increase our maintenance burden
• There isn't much value in generated YAML being idiomatic or human-readable. It's just a machine-readable intermediate for the kubectl apply command
• There's nothing Dhall-specific about this request. This could implement entirely as a YAML-to-YAML transformation and upstreamed into the Kubernetes project

[PierreR]

@Gabriel439 I agree with point 1 & 3.

I disagree with point 2 particularly in a context of tool adoption. When you try to bring a new tool into the table, the fact that the tool outputs non idiomatic yaml is a problem. In my context for instance, some teams will use dhall, others won't. Proposing something less disrupting ("look the output is the same") is a huge plus. In a migration path, you will end up with people that still prefer reading yaml over dhall.

It's just a machine-readable intermediate for the kubectl apply command

I would say this is not true in the context of Kubernetes. Yaml is still what most people read when they want to check a configuration. It is very much a human-readable configuration (even for me that is accustomed to the dhall syntax)

[jvanbruegge]

You don't actually have to use the kind: List. You can use the union (Resource):

let kube = ./kubernetes/package.dhall
in [
    kube.Resource.Namespace kube.Namespace::{ metadata = kube.ObjectMeta::{ name = "cicd-doc-dev" } },
    {- ... -}
]

If you export it with the--documents options of dhall-to-yaml you get the yaml you want. Not sure why this is not the recommended way in the README

[coderfromhere]

@Gabriella439 @jvanbruegge that ^^^ indeed should be explicitly recommended in the current FAQ of the readme, as the kubernetes API docs explicitly state:

Avoid depending on kind: List in automation or other code.

https://kubernetes.io/docs/reference/using-api/api-concepts/

[Gabriella439]

I put up a PR to update the README recommendation here: #183