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

Is obscurity SDL's biggest downside? When I was a D and DUB initiate, I had no issues acclimating to its usage, especially compared to SBT's DSL. Instead, the source of the friction was due to DUB's documentation, and there's already an effort to improve this.

It is safer to just go with whatever is used and accepted as a reliable format for configs. I like the idea to use plain D tbo.

JSON lacks comments, but it's fine for minimal default projects. We try to use TOML everywhere in a company, although I cannot say how well it works as a config for building projects. YAML is the most risky, since it has a high chance to alienate a sizeable amount of potential users.

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

https://json5.org/

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.

Currently, Dub uses two formats: JSON and SDL.
...
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!

what about this:
https://news.ycombinator.com/item?id=34351503
do we risk having a future effort and discussion again?

I don't like SDL probably because I don't know it and have never seen it used besides D. With JSON esp. JSON5 I can live, besides its massively used and well understood.

I do not see a real benefit in yet another file format for configuration.

On Tuesday, 28 February 2023 at 16:10:19 UTC, Steven Schveighoffer wrote:

This isn't what I'm talking about at all.

I don't want to run D to build, I want to introspect D for build info. You can read module names, dependencies (including platform-specific and configuration-specific ones) right out of D code. Author, description, license, etc., have standard ddoc sections in D code.

Other things dub.json define like flags could easily be a UDA on the module declaration and be pulled out pretty easily by compilers or even relatively basic parsers.

Even subconfigurations can... kinda be pulled out of D code by looking for version blocks though that's probably another thing I'd put on a UDA.

I do not see a real benefit in yet another file format for configuration.

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 ?