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

On Monday, 18 November 2019 at 10:44:18 UTC, Russel Winder wrote:
> On Mon, 2019-11-18 at 09:53 +0000, Paolo Invernizzi via Digitalmars-d-announce
> wrote:
> […]
>> A win-win move would be to have dud emit the other formats automatically as part of the compilation procedure, so to have always all of them present and synced on the content.
>
> Why? In fact, why even think of doing this at all?
>
> There should be one and only one human written configuration file for a build and it should be in a notation suitable for being written by humans.
>
>> It shouldn't be too much difficult, and maybe it's a cleaver way to move on from discussions about different formats.
>
> Again why? It seems like a pointless overhead that achieves nothing constructive.

Closing this kind of discussions and letting anyone to choose "tabs or spaces" is a constructive solution, I think.

That's the whole point of a win-win solution, anyone has a gain, the JSON party and the SDL party.

But, hey, as someone has to implement that, feel free to simply ignore my opinion ...

On Monday, 18 November 2019 at 13:19:12 UTC, Paolo Invernizzi wrote:
> Closing this kind of discussions and letting anyone to choose "tabs or spaces" is a constructive solution, I think.

It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\

On 11/18/19 3:54 AM, Jacob Carlborg wrote:
> 
> Perhaps this ship has already sail. But YAML would have been a better choice. It's a superset of JSON. All the existing JSON description files would have worked as is.
YAML's grammar is a convoluted read-only mess. Every time I have to write it I feel like I'm just guessing and hoping I'm magically writing it correctly. I've even had silent problems on travis-ci that turned out to be .travis.yml not being parsed the way I thought. That sort of thing shouldn't even be *possible* on a config file format.

Especially irritating to me is even just the basic nesting - the whole "sometimes you HAVE to use a hyphen and sometimes you have to OMIT the hyphen (or it'll silently be interpreted wrong)". And yea, yea, "Object vs array", whatever, but when you're using YAML for hand-written config files, the whole distinction between what should be objects vs arrays is just a big pile of arbitrary pointlessness (a flaw it inherits from JSON).

And the grammar being a superset of JSON doesn't really help much in practice, because real idiomatic YAML in the wild (including config file examples) doesn't use it.

On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:
>        - 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

As has been discussed elsewhere a few months ago, dependency resolution should be outsourced to an established SAT <https://en.wikipedia.org/wiki/Boolean_satisfiability_problem> solving lib, to avoid re-inventing a notoriously difficult wheel. This is what all the serious package managers have been moving towards, after invariably hitting problems (much like dub) trying to roll-their-own.

On Monday, 18 November 2019 at 10:40:28 UTC, Russel Winder wrote:
> On Mon, 2019-11-18 at 10:26 +0000, Sebastiaan Koppe via Digitalmars-d-announce wrote:
>> On Monday, 18 November 2019 at 09:53:56 UTC, Paolo Invernizzi wrote:
>> > A win-win move would be to have dud emit the other formats automatically as part of the compilation procedure, so to have always all of them present and synced on the content.
>> 
>> I already regret starting about this. Instead of rooting for the SDL format, I should have just recommended to deprecate the json one.
>
> I do not think you should regret starting a discussion on this.
>
> Personally I only ever use SDL with Dub. Even contemplating using JSON for human written configuration files is, for me, totally the wrong thing to do.

I only use the JSON format. JSON is widespread together with XML. SDL I heard first time of in the context of Dub and never seen it used elsewhere. TOML also I know only from Cargo. YAML at least I know from several different projects.

I guess the tool must be working very well though if the main argument is what kind of data format to use :)

On Mon, 2019-11-18 at 15:35 +0000, Joseph Rushton Wakeling via Digitalmars-d- announce wrote:
> 
[…]
> It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\

Perhaps because writing the configuration files is a critical part of the usability of the tool.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Mon, 2019-11-18 at 16:54 +0000, JN via Digitalmars-d-announce wrote:
> […]
> 
> I only use the JSON format. JSON is widespread together with XML. SDL I heard first time of in the context of Dub and never seen it used elsewhere. TOML also I know only from Cargo. YAML at least I know from several different projects.

It is so easy to make spelling errors in keys using hand-written JSON.

SDL I have only ever used with Dub, but it works better for me than JSON.

TOML is really an INI evolution so known to many.

YAML is used by many but doesn't really allow for the ease of specifying lists as TOML and SDL have.

> I guess the tool must be working very well though if the main argument is what kind of data format to use :)

Probably yes. Though Cargo has taken many different decisions to Dub and mostly I think Cargo took better decisions.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 18 November 2019 at 15:35:12 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 18 November 2019 at 13:19:12 UTC, Paolo Invernizzi wrote:
>> Closing this kind of discussions and letting anyone to choose "tabs or spaces" is a constructive solution, I think.
>
> It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\

Exactly, that's why I love pragmatism: let's dud emit the ones that are outdated, automatically.

Everyone can choose, work and update or the format he prefers, without impacting other people choices, and the discussion can move forward to something more interesting ...

my 2 cents, at least ...

On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote:

> Probably yes. Though Cargo has taken many different decisions to Dub and mostly I think Cargo took better decisions.

Could you elaborate a bit, please? I am not familiar with Cargo though.