March 03, 2023

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

>

JSON was there from the beginning, I assume due to Dub's npm inspiration.

Composer uses it, too.
(It’s not like NPM and DUB were the only ones to use it for package recipes.)

It’s a simple and commonly understood format, widely used (mostly for other use cases, of course) and feels similar to program code.

I assume most users are probably already familiar with it. Chances that someone has to “get into” this format just to use DUB are pretty low.

What do other languages use for their “package” descriptions:

  • Windows: Chocolatey: XML (+ JSON)
  • Go.mod: custom(?)
  • Java: Maven: XML
  • JavaScript: Bower: JSON
  • JavaScript: NPM: JSON
  • .NET: NuGet: XML
  • Nim: nimble: custom(?)
  • PHP: Composer: JSON
  • Rust: crates: TOML
  • Zig: zigmod: YAML
March 03, 2023
On Wednesday, 1 March 2023 at 21:20:15 UTC, Steven Schveighoffer wrote:
> On 3/1/23 4:04 PM, Mathias LANG wrote:
>> Forgot to answer this. YAML doesn't require any change (well, almost), because as of v1.30, dub parses dub.json using a YAML parser. As for configy, I provided a link: https://github.com/dlang-community/configy
>
> So the benefit of YAML is that you already infected dub with it?
>
> Another benefit of json5 then becomes, we can get rid of the YAML parser!

I wouldn’t phrase it this way, but “we already have a YAML parser in place” is not exactly a convincing argument to me either.

Like, JSON + SDL support is already in place as well (and even live, so zero effort needed!).
March 03, 2023
On Wednesday, 1 March 2023 at 07:41:02 UTC, tastyminerals wrote:
> YAML is the most risky, since it has a high chance to alienate a sizeable amount of potential users.

In my humble opinion it’s an awful format to write for users that only come in contact with it occasionally.

It’s easy enough to understand when reading it, but writing it is another story.

I don’t think switching to YAML will make DUB more accessible.
It’s too hard to get right without experience and DUB isn’t worth learning YAML when you have no other uses for it.

DUB recipes should be fun to write or they’ll needlessly end up low quality, i.e. people not bothering to create configurations, sub-packages in cases where they would make sense. If I have to lookup YAML specifics first to deploy advanced features, I will probably just not use them so I can get away (with not looking deeper into YAML than absolutely necessary).

Furthermore, the acceptance of DUB in the community is already noticeably less than it should be. Will the introduction of YAML improve this? Or will it cause a further hit to the acceptance?
March 03, 2023

On Friday, 3 March 2023 at 17:42:03 UTC, 0xEAB wrote:

>

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

>

JSON was there from the beginning, I assume due to Dub's npm inspiration.

Composer uses it, too.
(It’s not like NPM and DUB were the only ones to use it for package recipes.)

It’s a simple and commonly understood format, widely used (mostly for other use cases, of course) and feels similar to program code.

I assume most users are probably already familiar with it. Chances that someone has to “get into” this format just to use DUB are pretty low.

What do other languages use for their “package” descriptions:

  • Windows: Chocolatey: XML (+ JSON)
  • Go.mod: custom(?)
  • Java: Maven: XML
  • JavaScript: Bower: JSON
  • JavaScript: NPM: JSON
  • .NET: NuGet: XML
  • Nim: nimble: custom(?)
  • PHP: Composer: JSON
  • Rust: crates: TOML
  • Zig: zigmod: YAML

Zig doesn't use zigmod, it's a one of the community project, they have their own thing now, zig build, you use zig, and 'zon', wich is basically a zig file that returns a struct, to describe your packages/dependencies

Java doesn't use Maven, it's a dead format, most popular one is Gradle and it's Groovy or maybe Kotlin, i don't remember

I think trying to mimic what other language DID in the past isn't really helpful

What problem trying to solve? i think adam has the best idea, no need anything, stick to D, that's something worth experimenting with

And i wouldn't be surprised if the web people move towards that in the future aswel

https://deno.com/blog/you-dont-need-a-build-step

March 03, 2023

On Friday, 3 March 2023 at 18:04:06 UTC, ryuukk_ wrote:

>

Zig doesn't use zigmod, it's a one of the community project, they have their own thing now, zig build, you use zig, and 'zon', wich is basically a zig file that returns a struct, to describe your packages/dependencies

Java doesn't use Maven, it's a dead format, most popular one is Gradle and it's Groovy or maybe Kotlin, i don't remember

“…and Windows isn’t a programming language!!”
Anyway, that wasn’t the idea here. I was just quickly looking up stuff and pasted the first few things came up. Whatever…

Thanks for sharing your findings about Zig.

March 03, 2023

On Friday, 3 March 2023 at 17:14:45 UTC, 0xEAB wrote:

>

[..]
I’ve been using DUB for years, and still can’t remember SDL’s syntax.

The same applies to Dub's json format. I doubt many people can write a complicated dub.json file (e.g. with various configurations, platform & compiler specific D or LD flags, optional dependencies, git depedencies, and so on) without looking up the docs, or more likely browsing other D projects for inspiration.

>

[..]

Also, I’m curious:
Does anyone here in the community use it for anything else but DUB recipes?

Back in 2014 I was writing a toy ray tracer for a university project. Initially, I started using JSON for describing scenes, since it seemed like the obvious choice (and std.json among another things). Not long after I started the project I quickly got annoyed with JSON's lack of expressiveness(especially coming using XAML at work), and its lack of comments. Not long after I had started the project I learned that Dub was adding SDL format and I read DEP1 which convinced me to try and experiment with SDL. Then I gave it a go and extended my scene loader so it could load SDL (in addition to JSON) files. In the end, I liked the result, so I stuck with it. As I said, that was a toy project, so I don't have anything particularly interesting to show, but still, you may be curious to see an example of another D project using SDL as a human-readable data format:
https://github.com/PetarKirov/Chess2RT/blob/master/data/lecture5.sdl

March 03, 2023

On 3/3/23 12:14 PM, 0xEAB wrote:

>

Also, I’m curious:
Does anyone here in the community use it for anything else but DUB recipes?

I use it to configure my vibe-d project.

However, the existing SDL parser (sdlang-d) serializes to a DOM, which sucks for configuration. I want it to serialize to a struct I specify.

I'm presently working on adding json5 to iopipejson, and then I'm going to switch to that.

-Steve

March 03, 2023

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

>

Opinions ?

No fan of yaml, eventhough it is used a lot.

What about Amazon's ion?

March 03, 2023
On Friday, 3 March 2023 at 18:44:54 UTC, Petar Kirov [ZombineDev] wrote:
> On Friday, 3 March 2023 at 17:14:45 UTC, 0xEAB wrote:
>> [..]
>> I’ve been using DUB for years, and still can’t remember SDL’s syntax.
>
> The same applies to Dub's json format.

I’d say there a difference between syntax and mapping data to a format.
If you aren’t familiar with DUB’s JSON format, you can’t really claim that you were familiar with DUB’s SDL format either.

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.

Your IDE is probably also better at auto completing DUB recipe property names than general file syntax.
March 03, 2023
On Friday, 3 March 2023 at 22:12:46 UTC, 0xEAB wrote:
> Your IDE is probably also better at auto completing DUB recipe property names than general file syntax.

It'd be better if we had a JSON schema file for dub.json as well. If we were to get it into https://www.schemastore.org/json/ then VSCode at the very least would be able to make use of it automatically. Slightly less painful than having to tab between your editor and the dub.json documentation.