musicmatzes blog

As some people know, I am the maintainer of the config-rs crate. Right now, I am in the process of re-thinking the implementation and features of config-rs and am writing a “new generation” experiment, very creatively named config-rs-ng.

The config-rs-ng project is, as said, an experiment right now. If this experiment succeeds, it will replace the implementation of the config-rs crate.

Disclaimer: Don't use config-rs-ng in production code. Read the “Timeline” section below to understand why.

The Why

You might wonder why I am doing this. There are several reasons, but the main one is the following: The config-rs implementation does what I call eager merging of the configuration sources. To understand what that means, one must understand that the config-rs crate has the feature of “layering” configuration sources. A user of the crate can read different sources for their configuration and merge them so that former sources are shadowed by later sources. The implementation of the config-rs crate, upon instantiation of the configuration object, merges all config sources. That means, the actual information where a specific value comes from, is lost.

And that's an issue for several things: First of all, knowing where a configuration value comes from might be handy. If a user of the library wants to tell their users that a configuration value must be changed, they cannot tell the user where that configuration value must be changed. Also, re-loading parts of the configuration is not easily possible. Reloading the configuration would always mean that the whole set of configuration sources must be reloaded, to construct the full configuration object.

With the new implementation, the configuration sources are known, as the “merged object” is actually never constructed within the implementation of the crate. A user might opt into constructing a merged object if they wish, but they don't have to. The new implementation does not store one single configuration object anymore, but a list of sources that themselves store trees of their values.

This new approach might not be as memory efficient as the former approach, but we get several very nice benefits from that.

First of all, telling a user of an application that some value in the configuration must be changed can now happen with the information where that value is. Also, reloading parts of the configuration is now way less painful.

Current Featureset

The current feature set of the “ng efforts” is nowhere near what config-rs offers right now. Only TOML and JSON are implemented as format backends, very minimal async support is implemented, the API is still a bit noisy, the derive macro does only support structs, and also only structs with named fields.

Still, this could be the first moment I would call the codebase something like an “minimal viable product”. More or less, at least.

How you can participate

What I would like to ask the Rust community is: Please have a look. Tell me, preferably via issues, but also via mail or other channels:

• what you think is missing (at least for a MVP)
• what could be improved and how
• do you think that the current implementation is a good way to go
• what would you do differently
• what you don't understand

Of course, pull requests are even more appreciated than issues ;–)

The obvious things I know, which you don't have to tell me:

• More backends (TOML and JSON are nice, but we might also want YAML, KDL, INI,... we also should think hard about environment-variable support, although I am a bit hesitant because in config-rs that is a feature that is half-working and half-broken and I think is also rather hard to get right)
• Feature parity with config-rs in terms of deserializing to custom types and other API functionality
• Documentation
• Writing configuration. This is a rather hard topic, because we actually don't implement configuration formats, and writing configuration back must be format-preserving and all. I have that topic on my radar, but currently this is no priority for me (patches still welcome, of course)

If you want to dig a bit deeper, you are also welcome to read the vision document. If you can come up with ideas how to test the requirements listed there, that'd be highly appreciated as well!

Of course, patches for functionality and especially for feature-parity with config-rs are very welcome as well!

Timeline

The timeline for the config-rs-ng crate is: There is none. If and when the crate will become something that I feel comfortable with marking as “ready” (whatever that means) to replace the current config-rs implementation, is not decided at all. It is ready when it is ready, so to speak.

Also, I do not plan to release the config-rs-ng project as a dedicated crate on crates.io, because I don't want to mark this project as “official”/“official replacement of config-rs”! It is an experiment and if I think it is on a good way towards feature-partity with config-rs and I feel comfortable with it (and the feedback is not entirely negative), I will think about replacing the config-rs implementation with it.