3 ms·

Dhall's really cool because you can use it even if your tooling doesn't support dhall. There is direct JSON/YAML support with dhall-json: https://github.com/dha

Dhall's really cool because you can use it even if your tooling doesn't support dhall. There is direct JSON/YAML support with dhall-json: https://github.com/dhall-lang/dhall-json https://github.com/dhall-lang/dhall-json If you wanted to generate something like an NGINX config (or, for example, TOML or Terraform) you could use dhall-text: https://github.com/dhall-lang/dhall-text https://github.com/dhall-lang/dhall-text Oh, did I say terraform? Someone's already on supporting that directly: https://github.com/blast-hardcheese/dhall-terraform https://github.com/blast-hardcheese/dhall-terraform Dhall is very unique among configuration because it's "distributed", meaning that Dhall can load any file as a dhall expression, and has builtin URI resolvers to make even remote endpoints part of local configuration. This is excellent for, say, CI integration. Dhall has "semantic hashing" so that if someone does change a dhall dependency in a surprising way, the dhall script will refuse to continue (and give a very clear error about what changed, where it was looking for the change, and why it's stopping). Dhall is a secret superpower for project configuration. Especially as of the 1.14+ releases, it's become an increasingly go-to tool for me. Even in just one-off JSON generation scripts, I find it to be a lifesaver.

nv-vn 8y ago
Dhall is really similar to Nix in that regard, though in practice I've never seen Nix used for real configs (sadly). Usually trying to do so in Nix ends up being really ugly because the Nix features don't translate directly to concepts in the config language.
- chriswarbo 8y ago
  I dabbled in using Nix for this sort of thing, but it's rather painful to invoke the "Nix language" itself. In Nix 1.x we can evaluate a Nix expression (e.g. a templated string) like this: $ nix-instantiate --eval --read-write-mode -E 'Nix code goes here' That Nix code could be a file, or an import, or whatever. This is slightly improved with Nix 2.x: $ nix eval '(Nix code goes here)' Still, it's not particularly well suited to string processing from the commandline like this. We're closer to Nix's comfortable territory if we use it to build a config file, e.g. $ nix-build -E 'Nix code goes here' Or, more likely: $ nix-build myConfigFileDescription.nix In my experience this is more useful than trying to use Nix as a string processor. Still, if we're using Nix in a project or system, we might be better off using it to build the whole project (e.g. with a 'default.nix' file) or system (using a NixOS module or something). From what I've seen, Guix takes compatibility with non-Guix systems a little closer to heart, e.g. for generating standalone packages that don't require Guix to install/use.
antpls 8y ago
Sure, we can do all of that. But where is the cost analysis to justify adding more safety? I don't see how this couldn't be done whith a Python library. More people knows Python syntax, and more projects already have Python as a dependency. If that idea doesn't already exist in Python, is there even a need in the first place? Edit : downvoters are losers.
- KirinDave 8y ago
  Python is a Turing complete language that can do anything. Dhall isn't. That lack of power means that a configuration language can still do a lot, but stick to its mission of configuration. It produces a final value (probably a map or list). Your real program reads that value and does the real work. Why complicate your real program with that? Offload it to dhall and you get a consistent configuration for free! Think of all those places (e.g., Chef and Circle) where people try to encode graphs and processes in YAML. Dhall could do much of the same work of producing a simple spec, but without the fear of infinite loops or nonsensical Bash parameters hitting a function. Dhall is such a simple language (really just function application and and some built-in datatypes and access principles) that it doesn't seem terribly costly as opposed to, say, embedding a complex graph into YAML (risking structural errors) or Python (risking extremely complex behavior and execute-only configuration). If what you really want is a declarative set of instructions to your real program, Dhall is probably one of the most awesome tools in the open source world for making it.
  - antpls 8y ago
    You sound like a marketer trying to sell a fridge on a phone call. > Why complicate your real program with that? Offload it to dhall and you get a consistent configuration for free! Why complicate my projects pipeline and force my team to learn yet another tool that may just be abandonned in 3 months? > Dhall could do much of the same work of producing a simple spec, but without the fear of infinite loops or nonsensical Bash parameters hitting a function. Last time I wrote an infinite loop in Python was... I can't remember. Maybe 5 years ago? Nonsensical is subjective. Maybe Dhall only makes sense to you. > Dhall is such a simple language There is no objective criteria to define a "simple" language. Perl was simple to some people. > If what you really want is a declarative set of instructions to your real program, Dhall is probably one of the most awesome tools in the open source world for making it. Or you could write a nice Python library, with clean API, and eventually a linter that makes sure the Python configuration file is a restricted subset of Python.

nv-vn 8y ago

Dhall is really similar to Nix in that regard, though in practice I've never seen Nix used for real configs (sadly). Usually trying to do so in Nix ends up being really ugly because the Nix features don't translate directly to concepts in the config language.

chriswarbo 8y ago
I dabbled in using Nix for this sort of thing, but it's rather painful to invoke the "Nix language" itself. In Nix 1.x we can evaluate a Nix expression (e.g. a templated string) like this: $ nix-instantiate --eval --read-write-mode -E 'Nix code goes here' That Nix code could be a file, or an import, or whatever. This is slightly improved with Nix 2.x: $ nix eval '(Nix code goes here)' Still, it's not particularly well suited to string processing from the commandline like this. We're closer to Nix's comfortable territory if we use it to build a config file, e.g. $ nix-build -E 'Nix code goes here' Or, more likely: $ nix-build myConfigFileDescription.nix In my experience this is more useful than trying to use Nix as a string processor. Still, if we're using Nix in a project or system, we might be better off using it to build the whole project (e.g. with a 'default.nix' file) or system (using a NixOS module or something). From what I've seen, Guix takes compatibility with non-Guix systems a little closer to heart, e.g. for generating standalone packages that don't require Guix to install/use.

antpls 8y ago

Sure, we can do all of that. But where is the cost analysis to justify adding more safety? I don't see how this couldn't be done whith a Python library. More people knows Python syntax, and more projects already have Python as a dependency. If that idea doesn't already exist in Python, is there even a need in the first place? Edit : downvoters are losers.

KirinDave 8y ago
Python is a Turing complete language that can do anything. Dhall isn't. That lack of power means that a configuration language can still do a lot, but stick to its mission of configuration. It produces a final value (probably a map or list). Your real program reads that value and does the real work. Why complicate your real program with that? Offload it to dhall and you get a consistent configuration for free! Think of all those places (e.g., Chef and Circle) where people try to encode graphs and processes in YAML. Dhall could do much of the same work of producing a simple spec, but without the fear of infinite loops or nonsensical Bash parameters hitting a function. Dhall is such a simple language (really just function application and and some built-in datatypes and access principles) that it doesn't seem terribly costly as opposed to, say, embedding a complex graph into YAML (risking structural errors) or Python (risking extremely complex behavior and execute-only configuration). If what you really want is a declarative set of instructions to your real program, Dhall is probably one of the most awesome tools in the open source world for making it.
- antpls 8y ago
  You sound like a marketer trying to sell a fridge on a phone call. > Why complicate your real program with that? Offload it to dhall and you get a consistent configuration for free! Why complicate my projects pipeline and force my team to learn yet another tool that may just be abandonned in 3 months? > Dhall could do much of the same work of producing a simple spec, but without the fear of infinite loops or nonsensical Bash parameters hitting a function. Last time I wrote an infinite loop in Python was... I can't remember. Maybe 5 years ago? Nonsensical is subjective. Maybe Dhall only makes sense to you. > Dhall is such a simple language There is no objective criteria to define a "simple" language. Perl was simple to some people. > If what you really want is a declarative set of instructions to your real program, Dhall is probably one of the most awesome tools in the open source world for making it. Or you could write a nice Python library, with clean API, and eventually a linter that makes sure the Python configuration file is a restricted subset of Python.