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
