openapi-to-dhall generates deeply nested objects from CRDs

[BrianHicks]

Hey there! I'm trying to generate Dhall APIs for some Kubernetes CRDs, specifically these:

• https://github.com/argoproj/argo-cd/blob/master/manifests/crds/application-crd.yaml
• https://github.com/argoproj/argo-rollouts/blob/master/manifests/crds/rollout-crd.yaml

I'm having trouble, however, because openapi-to-dhall generates deeply nested types. That means I only get the benefits of the defaults at the top level, and would have to specify the types in all the Nones forever after down the tree. I suspect that other folks have dealt with this before (e.g. by pulling out field names to separate objects in a preprocessing step.) So I've got two questons:

1. Is this something folks have dealt with before? It seems like it should be possible to flatten the objects down to single-level records.
2. Is this something that openapi-to-dhall could do for me someday?

[BrianHicks]

Linking some stuff in! I think this is basically the same problem this person saw: https://discourse.dhall-lang.org/t/need-help-with-openapi-to-dhall/524

(h/t to @Arkham for finding this!)

[Gabriella439]

Yeah, my understanding is that openapi-to-dhall only generates types/defaults/schemas for top-level entries. However, I'd accept a pull request to support what you're requesting

[BrianHicks]

I implemented something like this with bash and jq and it works fine. I think it'd be better as a preprocessor step, honestly! In order to make it work you have to recursively flatten all the fields of records which have records (or lists of records, etc) as their type. To be honest, I think it'd be a lot of lens work in Haskell and I don't think I currently have the skill for it!