I think leveraging the vast existing body of JsonSchema artifacts is a more efficient road to success than transpiling schemata into XY.
XY being cue, nickel, the nix module system, etc.
I’ve toyed with the idea of making the backend modular. In other words, being able to choose between what tool is actually being invoked. So one could choose between JsonSchema, Nickel, Cue, Dhall, etc. My most recent revisions to
nixago have greatly increased the ability to do something like this.
As far as JsonSchema is concerned, moving it over to CUE is trivial (
cue import ...), but it is indeed an extra step.
nixago. See also:
Thanks, I’ll look into those. I’ve also added an issue for detaching the backend so that other tooling may be used.
v3.0.0 was recently pushed that overhauled the backend to be modular. It now uses
nixpkgs.formats as the default engine. See the updated README for more information. The plugins were also migrated to an external repository.
A little more elaborate example using