March 06, 2023

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



I mostly agree with Steve and others in this thread that we should go with JSON5. We can make the JSON parser accept JSON5 with a fully backward compatible manner (just like you did with YAML) and hopefully deprecate SDL so there is one canonical format everyone use (even though we silently keep supporting SDL).

What I would like to mention is that DUB has this add command for automatically adding a dependency (e.g. dub add vibe-d), and it is extremely broken to the core: It completely overwrites your file discarding all the formatting and even comments in a dub.sdl while also reordering json fields in dub.json alphabetically. It should have never existed in it's current form and should be removed.

March 06, 2023

On Monday, 6 March 2023 at 08:22:05 UTC, Ahmet Sait wrote:


It should have never existed in it's current form and should be removed.

Yes please, I would never recommend anyone to use "dub add" rather than just add a line.

March 06, 2023
On Thursday, 2 March 2023 at 13:56:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 03/03/2023 12:40 AM, Atila Neves wrote:
>> On Wednesday, 1 March 2023 at 18:13:35 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> I've been working on trying to get dub to build faster.
>> The simplest way is to get it to build per D package, in threads, and track dependencies. Which reggae does already, but it'd be nice if everyone else could benefit.
>> dub also takes quite a while to do mostly nothing, which reggae sidesteps by only asking dub for info when it generates the build instead of every time.
> Its significantly faster once you turn off networking.

I'm aware, I've had `db` aliased to `clear && dub build -q --nodeps --skip-registry=all` for many years now. It still does... something.

> There needs to be a local cache of packages rather than asking the dub-registry for everything all the time.

There is, it just doesn't look there. There's a reason why and Matthias is working on it.

March 06, 2023
Am 03.03.2023 um 18:14 schrieb 0xEAB:
> Also, I’m curious:
> Does anyone here in the community use it for anything else but DUB recipes?

I'm using it for a few little projects as configuration and document files, nothing big, but a few of them are in daily use by clients. I've written a little serialization adapter for those cases (vibe-sdlang).

One reason why I chose to adopt it was that it incidentally almost exactly matches a bunch of custom data formats that I defined for a game engine, just in a generic manner.

Those formats in turn were inspired by the approach that the Quake/Doom engines used, which was to define very concise and readable text based data formats based on a common tokenizer. Working with them was a true revelation compared to the typical XML (or JSON) based alternatives.
March 06, 2023
On 2/28/2023 8:10 AM, Steven Schveighoffer wrote:
>     import dparser;

I've been working on making the lexer/parser more amenable to being standalone. So far, the lexer is. The parser is close.
March 06, 2023
On 2/28/2023 8:32 AM, Adam D Ruppe wrote:
> 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.

This is a fine idea.

March 07, 2023
Am 03.03.2023 um 23:12 schrieb 0xEAB:
> On Friday, 3 March 2023 at 18:44:54 UTC, Petar Kirov [ZombineDev] wrote:
> ...
> If I’m already familiar with JSON in general, DUB’s manual will be all I have to worry about.
> If I’m not familiar with neither SDL nor DUB (which is more likely than not being familiar with JSON), I’ll end up looking at two manuals.

Literally the only thing that I think is worth looking up in the SDLang manual is line continuations. Everything else that is needed is already there in the DUB documentation by simply listing the directive itself. The value and comment syntax just matches D.

See - the examples there contain everything there is to know, and I think only the basic tag and nesting syntax is what really distinguishes it from a simple D subset (date/time/binary values, too, but they are not used by DUB).
March 08, 2023

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


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

Pure JSON. And only it.

Reason? It is rather simple, and super compatible. Easy to parse from anywhere, JavaScript, Python, Ruby, PHP, C++, C, syntax highliters on website, web frameworks, editors, formatters, command line tools (jq), etc. Do not assume dub files will only be consumed by dub.

YAML is horrible in my opinion. I use it a lot, and from a distance it looks nicer than JSON (comments, less verbosity, less quoting, etc), but it is not good in the long run. 1) YAML Parser are super complex. 2) backreferences are complicated. 3) multiple ways of doing same thing (strings, arrays, dicts), so you cannot easily read and write it back programatically, without likely messing diffs, 4) too many damn ways to write strings, 5) no quoting on values, causes issues when that value accidentally is integer/float-like or boolean-like (including word no). I hate this, and I just quote absolutely everything because of this, which defeats a big part of yaml. 6) multi-document feature is an anti-feature. 7) slow. 8) slow. 9) There is a lot of implementations, and in reality they all differ a bit in minor details. 10) slow. 11) Some extra features are just broken (like date parsing).

I use YAML a lot, in Ansible, Prometheus, Kubernetes, Github, Docker, and few other frequently used project. I never use it for personally build projects, because I do not like its complexity.

Only thing that would be nice in JSON to have: comments, trailing commas. JSON5 you say. I say no. Why? Compatibility. One can live without commas. Comments can be emulated using object keys, i.e. starting with underscore, and ignore them during processing. Multi-document can be easily done by just having JSON after JSON in one file (most parsers will just parse one at the time, and allow you to parse next object). Not that dub needs this feature anyway.

I do not like JSON either, but I do not like YAML, JSON5 and TOML even more. SDL is too XML-like (with attributes), but do not map nicely to processing in most programming languages (i.e. it is not just a dict / aa), and often require akward XML-like / DOM-like parsing, which is also more complex than it needs to be.

I would say YAML is okish, if the files are not too big, and you edit them literally every day. But the ones in dub, you edit only few very few times. So its human friendliness isn't really a good selling point to me.

But YAML spec is so big, has (or had) so many bugs, and issues, that I consider it horrible language.

Every few weeks I have some YAML issues, be it in Python, Go, Ansible. We even had few production outages caused by YAML idiotic parsing rules.

Simple, fast, and universal, is better than complex, slow and niche.


But JSON is a terrible format to write configurations in, given how verbose it is, and it lacking support for comments.

I do not agree with this statement.

You want comments. Just add them as underscore-prefixed keys. Or use //, which is rather easy to strip before passing to other tools.

If you want to comment some part of the config temporarily, then just remove it. Most people use version control. It will be in their history.

I would not consider JSON really a configuration language. It is more of a storage and data transfer format. Configuration languages are different things, there few decent ones out there, like jsonnet, Hashicorp's HCL, Dhall, and few more. The interoperability issue of them is not an issue, as: 1) there are actually few implementations, 2) they are not used directly by any system, rather they are passed through processing, and simple (flat and dump) format is used as output (usually JSON) to be consumed by programs. I like proper configuration languages like jsonnet, because otherwise you end up in some horrible templating like jinja in Ansible, or craziness of Helm Charts, K8s Kustomize, which are all just horrible hacks with poor usability. But, for dub using proper configuration language, would be an overkill in my opinion.

Personally I would use text-encoded protocol buffers. Schema based validation and typing out of the box. I use protocol buffers and text-encoded ones for configs in most of my personnel projects (Go, D, C++, Python), but it does come with some other tradeoffs (proto buffer definition files, extra compilation step, which is easy to automate, but a barrier for some).

But adding anything new is just not a good idea long term. You will need to support all the formats for years.

I think way more important than format of config is better documentation and tooling. Nodejs and TypeScript / JavaScript people use huge JSON files as config to build system, and it all just works fine.


March 10, 2023

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




I like the idea of YAML - it is readable! it is everywhere, we already have libraries to parse it, it has aliases and anchors that allows to simplify complex configs.
The slowness of parsing yaml is not an argument, from my point of view, because it will not be parsed too frequently.
But, may be introducing new config format, especially if there a lot of people that dislike it for some reason, is not a good idea.

In case of config files, i prefer readability. And in this case, SDLang fits nice - it is readable, and it is easy to work with it. So i think it is good to keep it.

About JSON (even JSON5) - i think it is not good for configuration. It is good for serialization, but not for manually adited configuration files: editing json manualy - is a pain. Using some hacks to add comments and enable trailing comma is not good idea.
I think comments are required feature for configs (there are cases when it is needed to explain why this options is set in this way and why it must not be changed or removed, or to describe options in config templates).
If we silently enable JSON5 syntax support for our json files, it also could lead issues with parsing json files by other tools (not dub itself). Using json5 as third format? May be we could find some better config format for third variant of configuration? Because deprecation of old formats could take years (there are some packages that had no new releases for few years, but seems to be working and useful, and i think we must not break them for no good reason).

Also, i think that it is not good idea to mix package configuration (description), that have to be read by other tools, with build scripts (d, lua, etc), that impretatively describes how to build the app/lib. Thus dub config must not be defined in any imperative language, instead it must be kept declarative.

So, in my opinion, we have to use YAML or some other readable/editable config format, or just keep SDLang with JSON and make SDLang default format for dub config.

1 2 3 4 5 6 7 8 9
Next ›   Last »