March 01, 2023

On Wednesday, 1 March 2023 at 21:02:05 UTC, Mathias LANG wrote:

>

On Wednesday, 1 March 2023 at 14:21:12 UTC, Steven Schveighoffer wrote:

>

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

I meant that the argument, in general, has been debunked. Also, SDL has significant whitespace in how it treats newlines.

>

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.

That's a problem we can work around, but having code to convert from SDL to YAML/JSON. We're already doing this (accidentaly) when downloading a package.

Couldn't it convert the file on the fly when it downloads dependency?

It's just data at the end of the day

March 01, 2023

On 3/1/23 4:02 PM, Mathias LANG wrote:

>

On Wednesday, 1 March 2023 at 14:21:12 UTC, Steven Schveighoffer wrote:

>

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

I meant that the argument, in general, has been debunked.

I'm thinking you are using "debunked" in the wrong way here. YAML (or anything else) using significant whitespace is not proof that significant whitespace is a good policy.

>

Also, SDL has significant whitespace in how it treats newlines.

That isn't what I am talking about. Anyone who has used YAML knows this isn't the problem that happens when you edit a YAML file.

> >

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.

That's a problem we can work around, but having code to convert from SDL to YAML/JSON. We're already doing this (accidentaly) when downloading a package.

Right, and dub is the one doing this. Dub fetches the package from the git hosting server (e.g. github), not code.dlang.org.

We still need an SDL parser in dub.

-Steve

March 02, 2023

On Tuesday, 28 February 2023 at 16:23:57 UTC, Mathias LANG wrote:

>

There's a whole world between "imperative" recipes (à la Makefile) and declarative ones.

Makefile is declarative though. And here's average yaml: https://github.com/dlang/dmd/blob/master/.cirrus.yml

March 02, 2023
On Wednesday, 1 March 2023 at 14:26:51 UTC, Adam D Ruppe wrote:
> 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...

Yes. The *vast* majority are "the code is in source, have at it".

> and dub's current thing tends to be inadequate for them anyway

Yes.

> especially since they generally need interop with third party things.

Yes.

As a build system, dub is a decent package manager (tongue firmly in cheek).


March 02, 2023
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.

> Dyaml appears to be a big ol' pile of slow code to build.
>
> So far I've shaved off 2s from its build, down to 22s with dmd.

This would be considered fast at work. Much to my chagrin.


March 03, 2023
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.

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

>> Dyaml appears to be a big ol' pile of slow code to build.
>>
>> So far I've shaved off 2s from its build, down to 22s with dmd.
> 
> This would be considered fast at work. Much to my chagrin.

Oh no.

March 02, 2023
On Thursday, 2 March 2023 at 13:56:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> Its significantly faster once you turn off networking.
>
> There needs to be a local cache of packages rather than asking the dub-registry for everything all the time.

There is already. If you have evidence of the contrary, please raise an issue (or better, a PR).
March 03, 2023
On 03/03/2023 5:24 AM, Mathias LANG wrote:
> On Thursday, 2 March 2023 at 13:56:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> Its significantly faster once you turn off networking.
>>
>> There needs to be a local cache of packages rather than asking the dub-registry for everything all the time.
> 
> There is already. If you have evidence of the contrary, please raise an issue (or better, a PR).

No, we do not currently store the entire dub-registry's package database locally. Which is what I'm talking about and yes it has been discussed on the issue tracker.


March 03, 2023

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.

What works well if you are using the same dependencies in multiple projects is -i plus symbolic links of all dependencies into the appropriate subdirectories. Changes to those libraries are reflected immediately everywhere, and updated with a git pull. You can add the symbolic link creation to the Makefile if you're working on multiple machines.

March 03, 2023
On Tuesday, 28 February 2023 at 14:29:28 UTC, Mathias LANG wrote:
> 1) Use SDL everywhere;

I’d prefer to ditch SDL.

It’s a lost bet from today’s point of view; nobody is using it elsewhere essentially.

Compared to other formats that are widely used (JSON, YAML, …), SDL can be perceived as “the bizarre format that one will only learn/use to write DUB recipes”.

I’ve been using DUB for years, and still can’t remember SDL’s syntax.
When I decide to use it, it’s only because it allows me to put "subPackage" + "dependency" next to each other, unlike the less flexible dub.json format. I don’t think this advantage is actually worth it, given this approach could get quite messy (esp. for other uses).

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