Hi there! I made a
Nix eDSL which can be translated into HCL, a language used by Terraform. In other words, we can use the power of
Nix to generate Terraform configurations. Here’s the project’s repository. Comments, issues and PRs are welcome!
Hi there! I made a
I’ve been using terranix, so I’m curious. How does terrafix differ and/or improve on what terranix has to offer? Thanks!
terrafixis an eDSL and it doesn’t suggest any new infrastructure or mechanisms. It is a means to produce
Nixcode. On the other hand,
terranixsuggests a module system, which is different from the Terraform’s one, documentation generation, and it compiles to
In author’s opinion, for debugging, finding the mapping between
.nixfiles is easier than between
.nix. Also, one may utilize Terraform’s Language Server to find the errors in the generated code. To add,
terrafixlooks pretty similar to HCL, so there is a highly error-prone script to convert the existing Terraform files into
.nix. It worked for simple examples though.
terrafixhas similar syntactic sugar, and, hopefully, the same compile-time safety due to
terrafix, it’s possible to use an accessor generated from previous blocks + add the missing fields:
image = config.resource.hcloud_server.myserver.image "id";
This will look like
image = config.resource.hcloud_server.myserver.image.id in the Terraform code.
Additionally, there will be a Nix compile time error if such an accessor is missing. Please, search the word
accessor on the README page of
terrafix to see more examples.
terranix, one may write
image = config.resource.hcloud_server.myserver.image;
However, the author is not sure if in
.json it won’t become a string stored in
terrafixcan (naively) render all Terraform’s standard functions. There seems to be no such functionality in
terrafixis an experimental language, so it has a lot of limitations. E.g. modules like
dockerMaincan only be mixed into an argument of
mkBlocks_of another module to make their variables available inside. See more limitations.