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.
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
Is there any chance you can be convinced to join our force to
improve Dub?
A lot of developers invested their time to either improve Dub in
general
or to get their needed scenarios running.
My gut feeling is, it would take years to rebuild the same set of
functionality
starting from the green field.
The code base of Dub isn't that bad. I also invested time and
there are some
parts you can easily get into. Of course there are also some
parts which are quite
complex but I would say this is caused by their nature
(Dependency resolution
is a quite complex topic).
But really the other parts are straightforward.
The biggest issue with Dub is to find out whether some specific
parts a bugs
or intended feature. But this issue you will also face if you
rebuild the
functionality of Dub. You never know whether it was intended or
it is a bug,
or you should it work.
Every effort which is put into Dub is immediately available for
the whole
D community, free developers and also companies from small size
to the biggest size.
(In no way I want to say you should not work on Dud, it is just
my hope we can
win you to help working on Dub).
Kind regards
André
