September 22, 2021

On Wednesday, 22 September 2021 at 10:19:18 UTC, Ki Rill wrote:

>

Out of curiosity, which one do you use in your dub projects and why do you prefer one over another?

For example, I use json. Simply because when I see sdl, I think of SDL2 graphics library.

What's your reason?

I use JSON. I am more familiar with JSON, never seen SDL used outside of dub and I find JSON cleaner.

September 22, 2021

i hate json, but that's the format i use

i wish we could just use a build.d file, so we can have more control and stick to using D

September 23, 2021

On Wednesday, 22 September 2021 at 14:57:09 UTC, Ki Rill wrote:

>

On Wednesday, 22 September 2021 at 13:22:33 UTC, Mike

>

SDL. It's much cleaner to me than JSON. And the fact that JSON is standard elsewhere matters not one iota to me.

What do you think of Rust's toml format?

Looks readable. Never used it though, so I don't know how it is to write.

September 23, 2021
On Wednesday, 22 September 2021 at 14:57:09 UTC, Ki Rill wrote:
> What do you think of Rust's `toml` format?

It's not 'rust's'; it's a general-purpose standardisation of INI which happens to be used by cargo.

IMO it's an excellent format for flat data, not so much for nested data.
September 23, 2021

On Wednesday, 22 September 2021 at 15:07:21 UTC, Ki Rill wrote:

>

On Wednesday, 22 September 2021 at 14:15:43 UTC, Steven Schveighoffer wrote:

>

I prefer a comment-allowing form, especially for config files, where comments can provide instructions on what directives do. Having dub init spit out a bunch of comments that describe how to configure dub, and how to add dependencies, configs, etc, would go a long way to making it not as bad a format.

-Steve

I wish json would accept comments. I prefer to leave lots of comments for future me in case I forget what I did, important information about a package, etc...

Json5 accepts comments

September 23, 2021

On Wednesday, 22 September 2021 at 10:19:18 UTC, Ki Rill wrote:

>

...

SDL. It's cleaner and easier to read, and I have no use cases where external languages need to read a dub.json file.

I agree that the acronym is unfortunate because of SDL2.

September 23, 2021

On Wednesday, 22 September 2021 at 10:19:18 UTC, Ki Rill wrote:

>

Out of curiosity, which one do you use in your dub projects and why do you prefer one over another?

For example, I use json. Simply because when I see sdl, I think of SDL2 graphics library.

What's your reason?

JSON.
I have a build tool that parses dub.json to extract meta-data from the project. A good SDL parser didn't exist back then.
As for TOML, its syntax for arrays is unfortunate, I don't feel like it's better than JSON (or even XML for what matters).

September 23, 2021

On Wednesday, 22 September 2021 at 21:25:11 UTC, russhy wrote:

>

i hate json, but that's the format i use

i wish we could just use a build.d file, so we can have more control and stick to using D

I would go with most simple syntax for simple builds - a command line syntax, where each command is a list of tokens separated by whitespace, the earlier example:

dependency sumtype 0.10.0
dflags -betterC -dip1000

and just fall back to D for complex builds, maybe with reggae api.

September 23, 2021

On Wednesday, 22 September 2021 at 21:25:11 UTC, russhy wrote:

>

i hate json, but that's the format i use

i wish we could just use a build.d file, so we can have more control and stick to using D

I would go with most simple syntax for simple builds - a command line syntax, where each command is a list of tokens separated by whitespace, the earlier example:

dependency sumtype 0.10.0
dflags -betterC -dip1000

and just fall back to D for complex builds, maybe with reggae api.

September 24, 2021

On Wednesday, 22 September 2021 at 10:19:18 UTC, Ki Rill wrote:

>

Out of curiosity, which one do you use in your dub projects and why do you prefer one over another?

For example, I use json. Simply because when I see sdl, I think of SDL2 graphics library.

What's your reason?

My thought about the missing comments:

The DUB-parser of the .json files might just remove all

  "comment": "My comment"

from the parsing result and we would have a way to place them.

  "comment": "List of authors is probably not complete"
  "authors": [
                "Martin Tschierschke"
        ],