dub: JSON, SDL, YAML, TOML, what color should we paint it ? (page 4)

Settings

Help

Index » General » dub: JSON, SDL, YAML, TOML, what color should we paint it ? (page 4)

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Adam D Ruppe
in reply to Bradley Chatha

Permalink

Adam D Ruppe

Posted in reply to Bradley Chatha

Permalink

On Tuesday, 28 February 2023 at 17:46:25 UTC, Bradley Chatha wrote:
> Have you written down a more refined version of these thoughts?

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_03_28.html
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_04_25.html


Even though more often than not, I just delete people's dub.jsons or makefiles or reggaefiles and what not and use a plain `dmd -i main.d` command (possibly adding more flags for configs) and it works reliably and like 2x faster than the other options.

I think people underestimate how well dmd -i works.

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Atila Neves
in reply to Adam D Ruppe

Permalink

Atila Neves

Posted in reply to Adam D Ruppe

Permalink

On Wednesday, 1 March 2023 at 14:06:29 UTC, Adam D Ruppe wrote:
> On Tuesday, 28 February 2023 at 17:46:25 UTC, Bradley Chatha wrote:
>> Have you written down a more refined version of these thoughts?
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_03_28.html
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_04_25.html
>
>
> Even though more often than not, I just delete people's dub.jsons or makefiles or reggaefiles and what not and use a plain `dmd -i main.d` command (possibly adding more flags for configs) and it works reliably and like 2x faster than the other options.
>
> I think people underestimate how well dmd -i works.

For most simple dub packages, I'd be surprised if it didn't. Any that actually need a build system, well...

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Steven Schveighoffer
in reply to Mathias LANG

Permalink

Steven Schveighoffer

Posted in reply to Mathias LANG

Permalink

On 3/1/23 4:21 AM, Mathias LANG wrote:
> On Tuesday, 28 February 2023 at 15:35:58 UTC, Steven Schveighoffer wrote:
>> Json5. It's json but with comments and allows key names without quotes.
>>
>> https://json5.org/
> 
> I didn't knew it supported quoteless keys, that's pretty nice!
> If it's a superset of JSON, we could potentially do it in place too.

It also allows trailing commas.

> 
>> 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 think the significant whitespace boat has sailed. I don't like it anymore than you do, but nowadays, editors align everything, and if they don't, the linter will complain, or the reviewer will. As much as I dislike it, I think significant whitespace just hasn't proved to be the barrier it was envisioned to be, as demonstrated by Python and YAML.

It hasn't sailed for dub. Neither json nor sdl require significant white space.

>> 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.
> 
> Note that going with YAML allows us to deprecate the SDL parser. Going with JSON5 includes writing a new parser, and a library to do what Configy currently does, on top.

We will never be rid of SDL. Remember that dub has to not only parse the current config, but all tagged configs. Updating all old projects, and all previous tags of old projects, is not going to happen.

JSON5 requires *updating* the existing JSON parser. JSON is valid JSON5, so I think we would be OK just parsing `dub.json` and `dub.json5` equivalently. Even if not, the parser can have a flag whether to reject JSON5-specific features.

Also, what is configy? And why wouldn't yaml also require changes?

-Steve

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Adam D Ruppe
in reply to Atila Neves

Permalink

Adam D Ruppe

Posted in reply to Atila Neves

Permalink

On Wednesday, 1 March 2023 at 14:12:11 UTC, Atila Neves wrote:
> Any that actually need a build system, well...

This is the minority of packages... and dub's current thing tends to be inadequate for them anyway especially since they generally need interop with third party things.

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Steven Schveighoffer
in reply to Mathias LANG

Permalink

Steven Schveighoffer

Posted in reply to Mathias LANG

Permalink

On 3/1/23 4:14 AM, Mathias LANG wrote:

On Wednesday, 1 March 2023 at 07:41:02 UTC, tastyminerals wrote:

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.

Why would YAML be the most risky choice ? For me it's quite the opposite: It's a well known and accepted format, AND the implementation is already there. So I clearly don't see how it would alienate users, except if those users are also alienated by Github Actions, Circle CI, Kubernetes, Ansible, Docker...

Because YAML is a huge, complex format. It not only contains a lot of specification, but has annoying rules (whitespace requirements) and has multiple ways of writing configuration -- within the same file.

JSON is much simpler. If YAML is chosen, I will stick with JSON. And so for many users, we add lots of complication for no benefit.

Even SDL has multiple ways of specifying things. It gets in the way. When there is one way to do something, you do that, and then you're done.

I'm not looking for artistry, cleverness or beauty in build files. I'm looking for structure and consistency.

-Steve

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Steven Schveighoffer
in reply to Atila Neves

Permalink

Steven Schveighoffer

Posted in reply to Atila Neves

Permalink

On 3/1/23 7:49 AM, Atila Neves wrote:

Having said that, having 3 formats is even worse.

Having a very similar format to JSON can lessen this impact. e.g. JSON5, which looks very similar to JSON and is backwards compatible.

I don't think we can talk about changing the format without having a plan for migrating every single dub.json/dub.sdl out there. I don't know how that'd work with issuing PRs to all of them, especially if the maintainers ignore them.

This isn't feasible. dub must parse and deal with not only the current configuration, but all prior configurations (in case you want to depend on prior versions).

We are stuck forever with both JSON and SDL as valid config formats, even if they are deprecated/undocumented.

-Steve

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Guillaume Piolat
in reply to Steven Schveighoffer

Permalink

Guillaume Piolat

Posted in reply to Steven Schveighoffer

Permalink

On Wednesday, 1 March 2023 at 14:50:16 UTC, Steven Schveighoffer wrote:

We are stuck forever with both JSON and SDL as valid config formats, even if they are deprecated/undocumented.

Unmaintained packages don't have that much value for the ecosystem.

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Steven Schveighoffer
in reply to Guillaume Piolat

Permalink

Steven Schveighoffer

Posted in reply to Guillaume Piolat

Permalink

On 3/1/23 10:05 AM, Guillaume Piolat wrote:

On Wednesday, 1 March 2023 at 14:50:16 UTC, Steven Schveighoffer wrote:

We are stuck forever with both JSON and SDL as valid config formats, even if they are deprecated/undocumented.

Unmaintained packages don't have that much value for the ecosystem.

These aren't unmaintained projects.

e.g. vibe-d has 207 versions. If you depend on version 0.9.5 (released on July 2022), that version used a dub.sdl, now what?

-Steve

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by tastyminerals
in reply to Mathias LANG

Permalink

tastyminerals

Posted in reply to Mathias LANG

Permalink

On Wednesday, 1 March 2023 at 09:14:17 UTC, Mathias LANG wrote:

On Wednesday, 1 March 2023 at 07:41:02 UTC, tastyminerals wrote:

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.

You are right, YAML is used in many places these days and good developers should not be having much trouble adjusting.

When I talk about YAML, I am referring to hundreds of frustration filled experiences that people eagerly share on hacker news or face-to-face when it comes to YAML. Starting from different IDE using different formatting and messing people's PRs, ending with scary stories about accidentally broken kustomizations causing prod outages. Because people make mistakes :/
It takes a few seconds to find a bunch of blog articles with some critique towards YAML and why you should not use it. Imagine how many beginners are getting inspired by such information and forming their own opinions.

Valid or not, there is a lot of hate towards YAML among developers. I am sure that adopting it has its benefits, it is used successfully in our company as well. What I am not sure of is whether the main building D tool needs this notoriety and mental "baggage". Once adopted, next thing you will see on this forum are questions why YAML for dub?

March 01, 2023

Re: dub: JSON, SDL, YAML, TOML, what color should we paint it ?

Posted by Petar Kirov [ZombineDev]
in reply to Bradley Chatha

Permalink

Petar Kirov [ZombineDev]

Posted in reply to Bradley Chatha

Permalink

On Tuesday, 28 February 2023 at 15:34:45 UTC, Bradley Chatha wrote:

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.

At this point, we may as well choose to use Nix given that its expression language is surprisingly expressive compared to how simple it is for a Turing-complete language (or its likely future successor - Nickel). Looking solely at its expression language, I'd say it's much better thought out compared to HCL, while if you look at the combination of Nix + Nixpkgs, it's undeniably a better fit for build systems.
The benefit of using Nix is that this would allow seamless integration with its huge collection of packages, which dwarfs those of most other system package managers. Of primary interest being the libraries which D can interface with via extern (C) / extern (C++) - e.g. for projects containing components written in mutiple programming languages. Another bonus point is how active its community is.

Top | Forum index | About this forum

Forums