dud: A dub replacement

[Robert Schadek]

On Monday, 18 November 2019 at 12:59:25 UTC, Joseph Rushton 
Wakeling wrote:
>
> 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?

My reason for making it cleaner is, because I assume this will 
give
me a build tool I can fix when broken. And hopefully it has less
bugs to begin with because its cleaner.

>
>       - 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

That is one thing yes.

>
>       - 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?

I'm not sure yet.

>
>   * 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 ... ?

It is build as a library first. The CLI is just using the library
constructs.

>
> 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

True, I'll work on that.

>
>       - 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 already started that, somewhat.

>
>   * 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

I know, I'll try to do better

>
>       - 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

Here is disagree, to a degree I consider comments a code smell.
If I have to write them, I failed to convey the information
needed to understand the code in the code.

>
>   * 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

Thank you