Nickel use-cases: tracking issue

[yannham]

Nickel potential applications

This issue gathers requests and ideas about specific Nickel usages (Cabal, Terraform, JSON Schema, etc.) scattered across the issue tracker or external documents.

• An alternative front-end language for Nix (nickel-nix, #693)
• Replace YAML as a the default language for writing project-specific tasks or scripts (www.taskfile.dev, just, Juan's do, etc.)
• Use Nickel to provision a Fedora Core OS, like Butane but modular and composable (#1047)
• Use Nickel to configure Cabal projects (#945)
• Use Nickel to write Terraform deployments (cf Terraform-Nickel)
• Use Nickel to write Pulumi deployments (could be a better fit than Terraform, given the design goals and approach of Pulumi to be a middleware between an external language and cloud orchestration)
• Use Nickel to write Kubernetes (cf https://tanka.dev/)

[matthew-healy]

I'd like to find a way to maintain GitHub Actions in Nickel, though as @aspiwack pointed out when I raised this in a review meeting, right now it's likely impossible to avoid the need to export the .yaml files before committing.

[jaen]

Nickel frontend for https://dagger.io/, maybe?

It used to be CUE-first, but now they have pluggable SDKs based on GraphQL. The official SDKs are for normal programming languages (they might or might not update the CUE one), but one based on a configuration language could probably be nice.

[arjinfo]

generate all the things like: https://hofstadter.io/

[ento]

Terraform data source that lets you provide data to modules that expect JSON or other structured data from a Nickel file. This would be analogous to this data source for dhall.

Examples

• aws_ecs_task_definition.container_definitions
• aws_iam_policy.policy
• Any homegrown configuration setup that reads values from an external JSON or YAML file, etc.

[emeinhardt]

Nickel seems to overlap with Dhall in a lot of ways, and there are potential use cases that Dhall almost is a good fit for, but which are out of Dhall's stated scope:

• Hosting semi-portable datatype specifications + human-readable, type-checkable serialized data.

Language-specific libraries supporting Dhall make typesafe (de)serialization between Dhall and ADTs in any given language that supports them look pretty seamless and more ergonomic than munging e.g. JSON...but Dhall's limits on string functions and recursive types bound its usefulness here: Nickel has neither of those a priori restrictions, though.