Pkl ("pickle") - new configuration language developed by Apple

A few days ago, Apple introduced Pkl (pronounced “pickle”), which is their take on a configuration language.

It aims to solve shortcomings of YAML, XML and JSON as configurations grow more complex. As ROS uses many of these configurations and as they can grow into cumbersome beasts, it could be beneficial to keep an eye on the reception of this new tool in the following months.

What do you think? Does this type of configuration language solve any of the gripes you have with configurations in ROS?

5 Likes

Makes me think of that one XKCD (“Standards”, https://imgs.xkcd.com/comics/standards.png)…

To be honest, I don’t (personally) have any gripes with passing rosparam information via YAML files, but that’s just me. I don’t love XML, but with ROS 2 there’s no need to deal with that any more. I suspect there won’t be a huge push to adopt this, unless it becomes so widely used that it replaces YAML. But I might be wrong.

I like the validation aspects. That could be useful.

2 Likes

I actually liked the approach of cartographer, using Lua files as they were config files.

I think more projects should try that!

EDIT: adding link for reference.

1 Like

There is a self-comparison of PKL with other formats in this page:

Static configuration formats such as JSON, YAML, and XML work reasonably well for simple configuration needs. However, they do have some shortcomings, including:

  1. They are not very human-friendly to read and write. (JSON, XML)
  2. They do not provide a way to split a large file into multiple smaller ones. (JSON, YAML)
  3. They offer no way or very limited ways to abstract over repetitive configuration. (JSON, YAML, XML)
  4. They do not offer standardized or widely available schema validators. (JSON, YAML)
  5. They offer little or no schema-aware tooling. (JSON, YAML)

For comparison with YAML, the valid points are 2 and somewhat 3 (the repetitive configuration may indicate other problems in the design and would be improved if 2 was a thing).

Yet I didn’t fully understand the concern about schemas as I think there is adequate schema support and tooling for YAML. Many big companies including Redhat and Adobe have various tools for JSON Schema (applicable on YAML). In the ROS ecosystem, the Autoware project employs JSON Schema for parameter validation. This is for quick and robust devel-time validation support for existing ROS parameter files. It does work well as far as I know.

Multi-file support is something I find necessary for large configurations. But it is a tooling and conventions problem rather than the language itself. JSON schema language itself has a nice multi-file concept and implementation for example.

1 Like

Lua as configuration files is incredibly powerful, and comes with the benefit of verification when run. Every project I’ve used that uses Lua for configuration has been very flexible.

2 Likes

thanks for sharing, very insightful!

As a community have we adopted TOML ? I am not aware of any such pushes for TOML which support greater validation too. Honestly I feel YAML does the job

I’m putting this in the bikeshed category.