Expense proposal: Turn dhall-kubernetes-generator into a standalone openapi-to-dhall project

#1

I would like to propose funding $250 to factor out dhall-kubernetes-generator into a standalone openapi-to-dhall project.

To provide some background: dhall-kubernetes internally uses a dhall-kubernetes-generator Haskell project to mechanically generate the Dhall types from the Kubernetes OpenAPI specification.

This dhall-kubernetes-generator is very close to being a functional openapi-to-dhall project, but just needs some some attention to take it across the line because currently it has some Kubernetes-specific details (like support for CRDs). For example, @tristanC reuses dhall-kubernetes-generator with a few patches to generate Dhall bindings to OpenShift based on their OpenAPI specification, too:

Also, a few people have similarly expressed interested in this on Twitter, too:

According to the expense guidelines I need to formally document the following:

  • What purpose is the expense for?

    To factor out the dhall-kubernetes-generator project into a standalone openapi-to-dhall project

  • Is this a one-time or recurring expense?

    One-time

  • What is the amount that you wish to expense?

    $250

Also, the expense has to be approved by the same process that we approve changes to the language standard

6 Likes
#2

I approve this proposal :+1:t2:

#3

Does this include modifications to the existing code or is this just a refactoring? For example:

  • The dhall-kubernetes-generator has some workarounds for kubernetes schemas that should be factor out.
  • Would it be difficult to implement the reverse action, e.g. generate openapi definition from dhall schemas?
  • Are we going to stick to the types/, defaults/ and schemas/ directory structure?
#4

@tristanC: Probably the easiest solution to maintain would be for the openapi-to-dhall project to include necessary hooks for dhall-kubernetes-generator to add the exceptions it requires. Also, the CRD logic could be kept entirely within the dhall-kubernetes-generator project.

It’s probably possible to go in the other direction, too, (e.g. dhall-to-openapi) and both directions could be part of the same project. I only mentioned one direction to keep the proposed work commensurate with the funding.

I’m also fine changing up the directory structure or making it customizable if another layout works better.

#5

Sounds like a great idea to me! :clap:

#6

One of the OpenAPI contributors reached out to me and asked what I thought about adding Dhall support to the openapi-generator project instead. I told them I would be fine with that if somebody was willing to do so, but that the main reason I suggested beginning from dhall-kubernetes-generator was so that the proposed work was commensurate with the funding. So they opened an issue here to check if anybody is interested:

If they find an interested volunteer within, say, the next week then we’ll try that route, otherwise I’ll proceed with the original proposal.

#7

Alright, we’ll continue with the original proposal and by the funding rules this should be approved.

#8

Hi Gabriel and all
Don’t know if its relevant but I have been working on encoding the OpenAPI schema in purescript lately. Doesn’t quite yet parse all the examples in the spec but not far out now.

Let me know if you’re interested in that as a starting point.

(The spec is a mess let me tell you)

A

#9

We have an existing implementation in Haskell, which is the dhall-kubernetes-generator referenced in the original post. It doesn’t handle all of the OpenAPI specification, but it handles enough to cover the Kubernetes OpenAPI specification at the moment. Most of the interesting logic is not in decoding an OpenAPI schema file, but rather converting that to an idiomatic Dhall package

#10

So far there are no takers for this, perhaps because the bounty is too low. Should we increase the bounty or cancel the bounty?

For reference our current balance is $737

#11

It would be great to have OpenAPI support!

I don’t have a lot of time to focus on this, but I signed up as a backer on OpenCollective in case it helps with efforts like this.

2 Likes
#12

I started the transformation process into a new dhall-openapi PR as I wanted to try the new RecordField type and embed definition documentation in the record. However I am not claiming this bounty and i’d gladly hand over that initial work if someone wants to complete the proposal.

#13

Given that nobody has picked up this task, yet, I will propose structuring this differently. If somebody is interested in doing this at a higher price then let me know and we can instead try to crowdfund the effort, including the $250 reserved for the task so far. We might be able to solicit more funding if people know that it is going to this task specifically.

#14

@Gabriel439 What would help to understand the necessary working effort is a division of technical tasks within the https://github.com/dhall-lang/dhall-haskell/tree/master/dhall-openapi repository.

Not sure I have the time or energy to start working on this to be honest but when I try to consider it that is kind of a blocking point for me :wink:

Thanks @tristanC for creating dhall-openapi already !