For lack of a better term, I'm calling the `{ Type = …, default = … }`
record that the record completion operator expects a "schema". This
change adds `dhall-kubernetes` support for auto-generating these schemas
for ease of use with the new `::` operator.
See the included example for how this would be used
In the case that an older kubernetes openapi is used, some of the
excluded models for newer versions will cause a necessary object for the
older kubernetes version to be filtered. In this case, showing the Kind
is helpful for debugging.
This ports the conversion script from Python to Haskell (fix#7)
The main reasons for this port are that:
- the Python script was really hard to maintain for reasons like
"converting from Swagger to Dhall is interleaved with string formatting"
- in Haskell we can use the dhall library to generate always syntactically
correct Dhall AST. It's also much easier to keep an eye on correctness,
because types and pattern matching. It also forces us to deal with things
like cyclic imports from the get go.
Things happening here:
- remove the `api` folder, removing the difference between "raw api" and "nice api"
- move defaults from `default` to `defaults` folder, as it is in `dhall-nethack`
- transition to the new syntax for `Optional` (fix#49)
- add `types.dhall` and `defaults.dhall`, so that one can now easily "pin a version"
by just importing these two records at a specific commit/tag. They also make it really
easy to access objects, e.g.
`let types = https://raw.githubusercontent... sha256:... in types.Deployment`
- also add typesUnion.dhall (fix#54), so one is able to send to Kubernetes different
objects in the same stream. This is also documented in the README
- defaults are resolved recursively (fix#46): if there's an import of a "nullable" record,
then it's not marked as Optional, making merging objects much easier
- default objects are not lambdas anymore, and instead they just don't include the required
fields (that is, the ones that are not nullable records), as suggested in dhall-lang/dhall-lang#382
- for objects that are simple types we used to generate a simple lambda
`\(a : Text) -> a` as a default, now we just don't generate a default (e.g. see
`io.k8s.apimachinery.pkg.apis.meta.v1.Time`)
- autoformat all generated Dhall code
- remove cyclic imports (fix#47)
- update to dhall-1.22 and dhall-json-1.2.8
This makes our build reproducible and consistent
* Disables dhall tests. They don't build in sandbox mode because they require network access
* Moves all scripts to ./scripts folder for consistency
* Moves all nix files to ./nix folder for consistency, except for release.nix which Hydra needs
* Changes convert.py to take the K8s swagger spec as an argument
* Get k8s swagger spec from nixpkgs
* Get dhall prelude from nixpkgs
* added an ./scripts/update-nixpkgs.sh script to easily update to a new version of nixpkgs
* We move all the example code from the readme to the `examples` folder.
* We provide a `scripts/build-readme.sh` script that inlines referenced
examples in `README.md.in` and outputs `README.md`. The script also
verifies that the output readme is the same as in version control.
* We provide a `scripts/build-examples.py` script that builds the Yaml
output for all examples. The script also verifies that the generated
Yaml files are the same as in version control.
As part of this I created a new files `./nixpkgs` that obtains a
specific version of the nixpkgs repo. This code was previously spread
between `release.nix` and `fetchNixpkgs.nix`. I also removed the Nix
1.11 code to simplify things. If we need Nix 1.11 support we can add it
again.
* We add the `glibcLocales` dependency to the somke test. This makes the
`en_US.UTF-8` locale available which is required for `dhall` to work
correctly.
* We also extract `check-sources.py` again so it can be run standalone.
`bash` and `dhall` which are required by the script are still
available when building it with nix.
We improve the convert code by rewriting the `get_typ`. It is now more
general and properly recurses on records and lists. This also surfaced a
bug where definition aliases did not generate correct code.
The `kind` and `apiVersion` properties of a Kubernetes resource are
already implicitly determined by the resource. We adjust the default
functions so that they do not require the `kind` and `apiVersion`
parameters for resources.
We obtain the implied values by inspecting the
`x-kubernetes-group-version-kind` key from the OpenAPI schema for that
resource. The [Kubernetes OpenAPI Spec Readme][1] explains how these
values determine the resource values.
[1]: https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/README.md#x-kubernetes-group-version-kind
