Enable `nix` as _config_ language

[blaggacao]

This is coming from thinking about nomad & terraform deployments.

In my thinking, we could bring the power of nix-lang to those tools by:

• Instead of defining hcl files, define nix files
• Render nix files to json
• Validate that json against upstream json schemata, such as: https://github.com/jboero/hashicorp-schemas/tree/master/JSON

Let me know what you think of this generic approach to use nix as the configuration language wherever json schemata are published...

[blaggacao]

Or the other way round: a jsonschema to nixpkgs module system converter? :smile: (for eval time validation without IFD)

Adios terranix, kubenix, etc.

[blaggacao]

Actually, thinking of it a bit more, the best option would be: builtins.JsonSchemaValidate attrs ./path/to/json/schema

[kamadorueda]

I like the idea, as writting complex terraform modules in hcl has been a pain many times, Nix allows for more intuitive constructs, functions, etc

The implementation of this I think would be modules like terraformTest accepting both src OR (not both) srcNix = asTerraformHcl { ... }

asTerraformHcl is an argument that dumps nix-lang to json and perform terraform-hcl schema validation

A point to take into account is that keeping compatibility with what people find in tutorials on the internet is important anyway, as for organizations like us migrating 14000 lines of code of HCL to Nix is not easy, fast nor cost-efficient. And for new-comers of Makes having to change so drastically can be daunting. I think it is better to offer both worlds, so we flirt with them slowly, allowing them to see the Nix benefits early and at their own pace, until they fall in love like we both did

[blaggacao]

I've run the idea of builtins.JsonSchemaValidate with a few people including elco & radvendii.

I think the general stance is: if that doesn't entail huge deps for nix, then hell yeah... (or maybe I'm just overly optimistic in my perceptions, which I usually am :smile: )

But realistically, I see that some consensus might be possible on this.

[blaggacao]

x-posting from matrix discussion, since I started breeding over this yesterday:

I think there is a wide open niche for lightweight merge semantics. The module system is too heavy, it requires to spec e.g. a JsonSchema via options, all be it that the JsonSchema can actually already validate the result through an IFD (with ajv for example). Or maybe even a future builtins.JsonSchemaValidate.

In order to give any base (json-y) configuration written in nix the capability of doing config overlays (e.g. for different environments), a variant of recursiveUpdate is required that:

1. Does not allow merging/overriding different types on the lhs & rhs (as a first sanity check).
2. If lhs is a list and rhs is a function, then apply that function to lhs. This allows simple & intuitive append & update semantics for arrays on the rhs with no need to specially prepare the lhs.

[blaggacao]

I might have cracked the classical array merge problematic in a very lightweight way that can work with arbitrary left-hand-side data structures (eg. coming from json or hcl).

https://gist.github.com/blaggacao/050483417bcab6a5cd126152b0187314