That is, is this project intended to allow one to translate one's nixos-config (configuration.nix) into Dhall? If so, is it sufficiently mature that anyone is actually using it that way?
@matthew-piziak: dhall-to-nix is probably not ready for this purpose. It's mainly a "proof of concept" executable. The main issue you will probably run into is that weakly-typed idioms from Nix/nixpkgs (such as builtins.listToAttrs and callPackages) don't play nice with Dhall.
Thank you @Gabriel439, that's exactly the info I was looking for. A blurb to this effect might be helpful on the README, don't you think?
Another difficulty you will have is that nixpkgs relies heavily on fix which is not supported in Dhall. I've worked around this in the past by having a top level .nix "evaluator", but it can feel a bit clunky.
@ocharles Good point!
You can always put the static parts of your config into dhall and read them in from your nixos config. It can be thought of as a typed JSON/YAML. You can even interpolate packages (by passing them as function arguments to the dhall code), but then you have to make sure to not use import from derivation (or the packages are built at evaluation time).
Honestly the thing I have the most trouble with is overrides. I spent an hour on #nixos last week and got two different suggestions as to how I might changing the patch-version attribute of Python—both were ugly and both were broken—and at the end of the day we gave up and pinned the package repository to an old commit. One attribute!
I like the idea of declarative configuration, and Nix is pretty much the only solution there, but the design of Nix can be quite bad in places. I'm looking for a way to escape it.
Allowing overrides is an instance of the expression problem afaik. There is an inherent difficulty to the problem. I don’t know whether dhall can help you much here.
Fix is up here: https://github.com/dhall-lang/dhall-haskell/pull/913
@matthew-piziak You nerd-sniped me.
Here’s an example of how to partially move overriding packages to dhall: https://github.com/Profpatsch/vuizvui/commit/964c248f18eaf13f4cfee0edcd2d4908c315c5a1
This could be taken a lot further, of course, but it shows that in principle it is possible to use dhall as a “typed nix plugin” that is used for a subset of package definitions, from nix expressions.
@Profpatsch I say this without exaggeration: I believe that an intuitive, well-documented style for overriding Nix packages may make the difference between life and death for the ecosystem.
This could be taken a lot further, of course, but it shows that in principle it is possible to use dhall as a “typed nix plugin”
The principle is very important! Even if the first-approximation translation isn't clearer at first, it might be easier to create a small set of natural wrappers in Dhall than it currently is in Nix.
Most helpful comment
Fix is up here: https://github.com/dhall-lang/dhall-haskell/pull/913