So dub has some problems, and personally I find its code base very hard to get
into.
At Symmetry we are a very heavy user of dub, resulting in many wasted hours.

So I started to write dud [1]. I kept some boring/nice parts from dub, but most
code so far is a complete rewrite.

The goal of dud is mostly do what dub does, but more understandable.
dud will/does aim for a tasteful subset of dub's features.
Meaning, most dub files should be good with dud.
If they are not, you will/should get an error message telling you whats wrong.
The bigger goal, at least personally, is to have a code base of pure functions
that is "trivial" to understand and debug.
The rules of thumb is: "When your line gets longer than 80 characters,
restructure your code!", "Branch statements are code smells."

So what can dud do right now.

$ dud convert

works.
IMO that is an important step, as this involves ingesting dub.(json|sdl) into
a common representation.

I use dubproxy [2] to get all ~1.6k packages from code.dlang.org and create a
git working tree for all the versions of all the packages.
Currently, that results in ~60k (package|dub).(json|sdl) files.
Then, I run dud on those and see what breaks.
Only a few percent are not ingestable by dud, and those are in IHMO not valid
anyway (to be fair, there is some strange 💩 out there).

Now that dud can parse dub files, the next step will be a semantic phase,
checking the input for errors.
After that, path expansion and dependency resolution.

PR's are always welcome.

Destroy!

[1] https://github.com/symmetryinvestments/dud
[2] https://github.com/symmetryinvestments/dubproxy

On 2019-11-11 14:44, Robert Schadek wrote:
> So dub has some problems, and personally I find its code base very hard to get
> into.
> At Symmetry we are a very heavy user of dub, resulting in many wasted hours.
> 
> So I started to write dud [1]. I kept some boring/nice parts from dub, but most
> code so far is a complete rewrite.

Hmm, that's unfortunate. It happens way too often in the D community, that a project is rewritten from scratch instead of improving the existing one. Especially since the D community is not that big.

Although I can understand the choice. Even if you were to contribute there would be no one to merge the pull requests :(.

-- 
/Jacob Carlborg

On Monday, 11 November 2019 at 13:44:28 UTC, Robert Schadek wrote:
> So I started to write dud [1]. I kept some boring/nice parts from dub, but most
> code so far is a complete rewrite.

Someone's eventually going to say this, and they probably really
won't want to, so I'll spare them: this is a horrible name. Is it
even deliberate? Is it only accidentally a meaningful English
word?

https://en.wiktionary.org/wiki/dud#Noun

(informal) A device or machine that is useless because it does not work properly or has failed to work, such as a bomb, or explosive projectile.
(informal) A failure of any kind.
(informal) A loser; an unlucky person.
A lottery ticket that does not give a payout.

Maybe this is in the tradition of tool names that have bad
connotations but are actually intended to be meaningless, like
Fedora's dnf (Did Not Finish). Or even horrible, disgusting
connotations, with the hope that this will serve as an
attention-getter followed by the reader being unwilling to concede
that emotions can interfere in technical decisions.
( https://duckduckgo.com/the%20open-source,%20cloud%20native%20SQL%20database )

On Monday, 11 November 2019 at 19:17:54 UTC, Jacob Carlborg wrote:
> [snip]
>
> Hmm, that's unfortunate. It happens way too often in the D community, that a project is rewritten from scratch instead of improving the existing one. Especially since the D community is not that big.
>
> Although I can understand the choice. Even if you were to contribute there would be no one to merge the pull requests :(.

Yeah...it was wondering if there was a way to have like a dub-core that both dub and dud can depend on.

On Monday, 11 November 2019 at 13:44:28 UTC, Robert Schadek wrote:
> So dub has some problems, and personally I find its code base very hard to get into.
> At Symmetry we are a very heavy user of dub, resulting in many wasted hours.

I'm interested in which areas does you and/or Symmetry find dub not delivering expected results? Is it package management in general? Build process? What's the actual need to rewrite dub again?

I started working on a build tool to replace dub for my personal projects some time ago because I grew tired of long build times when only small portion of the project was touched. This last month I decided to rewrite it and work on it more actively, and I've already managed to get some huge libraries like vibe-d and serve-d building. I have no plans to rewrite the dub as a whole, but only focus on the build command, leaving the package management to dub which I have personally no problems with.

On 11/11/19 8:44 AM, Robert Schadek wrote:
> 
> The goal of dud is mostly do what dub does, but more understandable.
> dud will/does aim for a tasteful subset of dub's features.
> Meaning, most dub files should be good with dud.
> If they are not, you will/should get an error message telling you whats wrong.
> The bigger goal, at least personally, is to have a code base of pure functions
> that is "trivial" to understand and debug.
> The rules of thumb is: "When your line gets longer than 80 characters,
> restructure your code!", "Branch statements are code smells."
> 

Sounds cool!

> Only a few percent are not ingestable by dud, and those are in IHMO not valid
> anyway (to be fair, there is some strange 💩 out there).

From what I've seen, dub tends to take the approach of "silently ignore anything in dub.sdl I don't recognize as valid". I'll admit that may be an important approach for a tool that has no concept of its own changing versions (which is somewhat strange for dub, considering half of dub is a package manager.) But the flipside is that this fosters and breeds errors and invalid files in the wild (see: 90's era web browsers).

I'm curious, are there any particular anti-patterns you've noticed as being common in the uningestible repos?

On Monday, 11 November 2019 at 13:44:28 UTC, Robert Schadek wrote:
> Now that dud can parse dub files, the next step will be a semantic phase,
> checking the input for errors.
> After that, path expansion and dependency resolution.
>
> PR's are always welcome.
>
> Destroy!
>
> [1] https://github.com/symmetryinvestments/dud
> [2] https://github.com/symmetryinvestments/dubproxy

Are you looking to replace dub as the reference build tool for D? (Please say yes...)

Any estimate what the schedule looks like until dud can be used in practice?

On Friday, 15 November 2019 at 10:29:07 UTC, FeepingCreature wrote:
> Are you looking to replace dub as the reference build tool for D? (Please say yes...)

reference build tool, I don't know. We will see.

>
> Any estimate what the schedule looks like until dud can be used in practice?

dub convert works already ;-)

No, PR's welcome

On Thursday, 14 November 2019 at 23:33:06 UTC, Nick Sabalausky (Abscissa) wrote:

> From what I've seen, dub tends to take the approach of "silently ignore anything in dub.sdl I don't recognize as valid". I'll admit that may be an important approach for a tool that has no concept of its own changing versions (which is somewhat strange for dub, considering half of dub is a package manager.) But the flipside is that this fosters and breeds errors and invalid files in the wild (see: 90's era web browsers).

Also, this, apparently, should lead to the fact that dud will have their own package description format. Almost inevitable. (This has already been discussed, perhaps.)

On Monday, 11 November 2019 at 13:44:28 UTC, Robert Schadek wrote:
> So dub has some problems, and personally I find its code base very hard to get into.

I understand what you mean. What I found most disruptive to my internal model of the code is the mutable state. It prevented me from a solid understanding of all the parts.

> The bigger goal, at least personally, is to have a code base of pure functions
> that is "trivial" to understand and debug.
> The rules of thumb is: "When your line gets longer than 80 characters,
> restructure your code!", "Branch statements are code smells."

I certainly applaud your goal and I think many parts can be improved upon. However, not everything is accidental complexity; sometimes problems are hard and code is non trivial. Although in almost all cases it can be made nicer, it is just a matter of how much time you want to spend on it.