humphrej / rules_dhall

Bazel rules to build dhall configurations

rules_dhall

This repo contains experimental rules for bazel to generate files using Dhall.

The rules use the method described by @Gabriel439 in this answer on stack overflow.

rules_dhall fetches binary releases of dhall from github - see section command targets.

Rule reference

dhall_library

This rule takes a dhall file and makes it available to other rules. The output of the rule is a tar archive that contains 3 files:

• the binary encoded, alpha normalized dhall expression (.cache/dhall)
• the dhall source file (source.dhall)
• a placeholder that includes the sha256 hash (binary.dhall)

Attribute	Description
name	string; required.
entrypoint	label; required. This is name of the dhall file that contains the expression that is the entrypoint to the package. Any dhall references from another dhall package must include the sha256 hash.
srcs	List of labels; optional. List of source files that are referenced from entrypoint.
deps	List of labels; optional. List of dhall_library targets that this rule should depend on.
data	List of labels; optional. The output of these targets will copied into this package so that dhall can reference them.
verbose	bool; optional. If True, will output verbose logging to the console.

See example abcd.

dhall_yaml / dhall_json

This rule runs a dhall output generator. The output of the rule is the YAML or JSON file.

Attribute	Description
entrypoint	label; required. This is name of the dhall file that contains the expression that is the entrypoint to the package. Any dhall references from another dhall package must include the sha256 hash.
srcs	List of labels; optional. List of source files that are referenced from entrypoint.
deps	List of labels; optional. List of dhall_library targets that this rule depends on.
data	List of labels; optional. The output of these targets will copied into this package so that dhall can reference them.
out	string; optional. Defaults to the src file prefix plus an extension of ".yaml" or ".json".
verbose	bool; optional. If True, will output verbose logging to the console.
args	List of string; optional. Adds additional arguments to dhall-to-yaml or dhall-to-json.

See example abcd

Command targets

To run dhall or dhall-to-yaml via bazel:

bazel run //cmds:dhall -- —help
bazel run //cmds:dhall-to-yaml -- —help
bazel run //cmds:dhall-to-json -- —help

Usage with dhall-kubernetes

It is possible to use these rules in combination with dhall-kubernetes. See example k8s.

Note on freezing dependencies

rules_dhall relies on the semantic integrity checking feature of dhall. For this to work, expressions referenced from another dhall package must include the sha256 hash. See "dhall freeze" for details.

Note on hashing

To find the hash for a given package/tar:

$ bazel run //rules:dhall-hash -- <path to tarfile>

rules_dhall's Issues

integration with rules_k8s?

Thanks for these great bazel rules @humphrej !

I'm curious if anyone has tried hooking up rules_dhall with rules_k8s to define k8s configs in dhall with https://github.com/dhall-lang/dhall-kubernetes, and then deploying them with rules_k8s? It seems like it would have potential to be an amazing workflow! At least I would certainly use it!

Thoughts on `providers` and `toolchains`?

Heya, thanks for putting this set of rules together!

I'm curious if you've thought about converting things over to providers and toolchains.

Providers allow passing information between rules. E.g. the three files that are currently archived up could instead be plain files that are shuffled along in a DhallInfo-esque provider. This would mean that there wouldn't need to be an implicit dependency on tar. It'd also mean that there would be fewer shell scripts to write (maybe none) to deal with the archiving/unarchiving.

Toolchains allow describing the interface for each tool being used to decouple the rules from the selection of which tool to use. E.g. There wouldn't be a reason to search for the proper binary on the path, it'd be done at repository resolution time. This would mean that all platforms that are supported by the dhall-haskell repo are immediately supported by rules_dhall. This could also mean that assuming the toolchain defined the interface appropriately, other Dhall implementations could be used without burdening rules_dhall unnecessarily. dhall-golang in particular would be interesting because in theory it could compile to many different platforms.

If you're interested in discussing further or would like to see a PR, lemme know.