Currently, Dub uses two formats: JSON and SDL.

JSON was there from the beginning, I assume due to Dub's npm inspiration.
In fact, we still very much depend on JSON internally: until recently, JSON object were passed around in quite a few places. When we download a package, regardless of the format the package recipe is in, we store it as dub.json.

But JSON is a terrible format to write configurations in, given how verbose it is, and it lacking support for comments.
So around 2014, we added support for SDL (no, not this one, or this one, but this one, and it took me 10 minutes to find the link because Wikipedia doesn't even know about it).

At some point last year, I did some heavy refactoring on dub along with quite a few improvements. In the process of doing so, I took advantage of the fact that YAML is a subset of JSON to add a YAML parser, on which I have built a library to do automatic configuration parsing, because let's be honest, it's 2023 and we're using the language with the best compile-time reflection capabilities, so we really don't want to manually parse a standard file format to fill a struct.

This parser is used to parse all JSON files:

• dub.json (but not dub.sdl);
• dub.selections.json;
• dub.settings.json;

Now, I think that having dub.settings.json being written in JSON doesn't make sense, and I would like to change this. In fact, I have been wanting this for more than 3 years, and the people that took part in the discussion broadly agreed.

Here are the options that have been floated around:

1. Use SDL everywhere;
2. Add support for YAML;
3. Add support for another format (E.g. TOML);

I would like to go with YAML, not because it is the greatest format on earth, but because SDLang is not well known (it means newcomer have to learn yet another format, and while not a big deal, it adds friction), while YAML is everywhere. In the thread were SDL was discussed, people even thought we invented it!

In practice, this would mean adding support for the file format with a YAML extension, giving it priority over the old format, then after a number of releases (most likely 10, probably more for dub.json), deprecating the JSON / SDL equivalent.

Obviously such a change would not happen overnight, and would need broad support from the community. Opinions ?

I don't enjoy JSON so i gave SDL a try few months ago, i quickly gave up, can't add new lines, can't add 'platform' at the beginning, nice for hello worlds, horrible for real world projects or simply when you need to manage multiple configuration

JSON doesn't support comments, it's noisy, and inflate the number of indentation for no reason

YAML is nice, a simple INI even better, LUA even more better (premake/xmake anyone?)

LUA would make managing multiple configurations easier, i'd experiment with adding it, but DUB takes an eternity to compile for me to do any work with it unfortunately

On Tuesday, 28 February 2023 at 14:29:28 UTC, Mathias LANG wrote:

IMO JSON just needs to go. It has no purpose being used in dub for anything user-facing.

I do like SDL however it's a bit of a "dead end" language, so is definitely worth trying to move away from going forward.

TOML makes my eyes bleed and I don't understand at all how anyone likes it.

YAML is decent to mentally parse, but writing it can be a bit frustrating, especially if you don't have a schema setup in your code editor.

Considering dub is also a build system and not just a package manager, I wonder if we could take a note out of other build managers and use something stronger than basic config language. e.g. Meson has their own language; Bazel uses Starlark, CMake has abomination. If not instead embracing dub as a package manager, and another existing tool as a build system.

My personal pipe dream is that we'd use CUE: https://cuelang.org/ - however disregarding the relative complexity of a native D implementation, the language itself is still unstable (no v1 release). I can dream though ;D

Another example are the likes of XMake that use Lua, though I am always skeptical about using a full language for build systems. (Side node: I've had ideas in the past that you could use something like Lua to define jobs/stages that could then be used from a declarative/config language to then describe the build.)

Considering the likes of rdmd existing, you could technically even just use D itself...

So ultimately is the discussion more "Which language should we use" or instead "What exactly do we want dub to do and be capable of?"

On Tuesday, 28 February 2023 at 15:22:41 UTC, Bradley Chatha wrote:

Adding onto my reply: Adopting HCL could be a potentially strange but interesting choice since it has a slightly more extensive (though still limited) feature set for a config language, namely: interpolation; ability to call but not define functions, and support for certain kinds of expressions such as list comprehensions (at least I think that's native to the language and not a Terraform addon).

Of course there's still the lack of an implementation available to D though.

On 2/28/23 9:29 AM, Mathias LANG wrote:
re are the options that have been floated around:

Json5. It's json but with comments and allows key names without quotes.

https://json5.org/

"JSON5 was started in 2012, and as of 2022, now gets >65M downloads/week, ranks in the top 0.1% of the most depended-upon packages on npm, and has been adopted by major projects like Chromium, Next.js, Babel, Retool, WebStorm, and more. It's also natively supported on Apple platforms like MacOS and iOS."

I have to say, I hate YAML. With a passion. The "backwards compatibility with JSON" is pretty must just bolted on. And having multiple ways to write configurations might be nice for people writing configs, it's not nice for people reading them. Also, significant whitespace = bad.

I would be OK with TOML. But then we have 3 formats. Changing to a json-compatible format means we still only have to maintain 2 parsers.

-Steve