dud: A dub replacement

[Andre Pany]

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é