Nickel and external configuration languages

[nwmcsween]

I'm wondering how Nickel plans on interfacing with external configuration languages (nginx, etc)? I understand this is out of scope for Nickel but I don't want to see Nickel having a few thousand contracts and becoming yet another templating language for $external_configuration_lang.

[yannham]

For now there are no concrete plans for this, but this is a good point to consider. As you say, the zero level of interfacing would be to write strings and interpolate Nickel values in it directly, but it's not very nice. Another solution is to write a generic serializer as a library, but in pure Nickel directly, without needing special support from the interpreter. For example, a function to_nginx : NginxValidConfig -> Str taking a record, or whatever data represents a nginx config well and return the config.

Then your Nickel configuration could look like:

{
  user = {user = "www", group = "www"},
  worker_processes = 5,
  error_log = "logs/error.log",
  pid = "logs/nginx.pid",
  worker_rlimit_nofile = 8192,

  events  = {
    worker_connections  = 4096
  },

  http  = {
    include = ["conf/mime.types", "/etc/nginx/proxy.conf", "/etc/nginx/fastcgi.conf"],
    # ...
  },
}
|> to_nginx

nickel export myconfig.ncl --format raw would give:

user       www www;  ## Default: nobody
worker_processes  5;  ## Default: 1
error_log  logs/error.log;
pid        logs/nginx.pid;
worker_rlimit_nofile 8192;

events {
  worker_connections  4096;  ## Default: 1024
}

http {
  include    conf/mime.types;
  include    /etc/nginx/proxy.conf;
  include    /etc/nginx/fastcgi.conf;
...

One of the reason (albeit not the only) to allow arbitrary recursion in Nickel was that for some use-case, like Bazel, you end up needing to write simple parsers and serializer for obscure formats by hand, and it's nice when the language can do so without too much pain.

Of course, it may prove not very performant for big configurations, especially at the time being. If some formats are common, I guess we can consider adding them to the possible format flag of nickel export, but those have to be very common, because the burden of maintaining the serializer would then be the responsibility of the Nickel maintainers.