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).

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.

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.

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).

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.

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?