dud: A dub replacement

[Joseph Rushton Wakeling]

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.

Cool :-)  Since I have also been experiencing a fair bit of 
production-use DUB pain in the last year, I really appreciate 
your taking action on this.

A few things that would be good to understand up front:

   * what are the particular issues with DUB that you want to 
address?

       - making the codebase cleaner and more functional is 
obviously
         nice but is at most a means to an end -- what's the real 
end
         you have in mind?

       - I would imagine getting dependency resolution really right
         would be top of the list -- it would be good to aim to fix
         issues like https://github.com/dlang/dub/issues/1732

       - I would personally really appreciate it if you would make 
it
         a design goal to better separate concerns in terms of what
         DFLAGS are used and why (for example, the fact that right 
now
         `dub test --build=release` will not actually run 
unittests,
         as `--build=release` drops the `-unittest` flag)

   * are there any particular known issues with DUB that this 
definitely
     will NOT address?

   * are there any key _breaking_ changes you have in mind?

   * where does this stand w.r.t. some of the proposals to break 
DUB apart
     into more cleanly separated components, e.g. determining 
compatible
     dependencies, downloading dependencies, building or running 
tests ... ?

Some concrete feedback on the project as it stands:

   * the tickboxes of compatible commands are nice, but it would 
be good to
     have a more contextualized roadmap, in particular outlining 
the design
     concerns for core data structures and functionality

       - this should probably be in issues rather than the README, 
but
         it needs to be somewhere, otherwise it's hard for anyone 
outside
         to identify things they can do

       - it might be nice to use a GitHub project to manage things 
so that
         us outside folks can identify better what's being worked 
on and
         what's blocked by what

   * I don't mind breaking changes in either the config format or 
the command
     line API if it gets us to a nicer tool, so please embrace the 
opportunity
     where appropriate

       - I can imagine this might be the reason why the aim is to 
support
         a "tasteful subset" of DUB's features: it means that 
others can
         be re-implemented in an incompatible but better way

       - auto-conversion mechanisms may be preferable to outright 
support
         for old formats and commands

   * I really recommend trying to start writing clean, clear 
commit messages
     from the very start -- think of this as another form of code 
documentation
     that communicates to all interested readers the intent and 
considerations
     behind any particular change to the codebase.  This makes it 
much easier
     for outsiders to get a clear understanding of the project and 
get into the
     habit of contribution

       - right now, pretty much all the commit messages read like 
spontaneous
         notes where even YOU won't remember the whys or 
wherefores in a few
         months' time

       - long term it saves a LOT of time when trying to look back 
and understand
         "Why did we do things that way?" -- particularly useful 
when trying to
         fix some subtle design bug

   * for the same reasons, really try to provide good 
documentation and comments
     for all code from the start -- this really makes it much 
easier for anyone
     interested to grasp the major design concerns and get 
contributing

   * these concerns are going to be strongest for the key data 
structures and
     algorithms -- please make sure these are REALLY documented 
well, from the
     very start

Hope all of that's helpful, and best wishes for taking this 
forward -- I will try to help as I can, but time right now is 
very constrained ... ;-)

Thanks & best wishes,

      -- Joe