So, DUB support is moving along nicely in DDT, but there are some issues
with 'dub describe' that could use some fleshing out. It basically boils
down to this, all 'dub describe' output (at least stdout output) should
be supplied in JSON so that it can be processed in a standard way.

For example, even with 'dub describe' DUB throws some error and exits if
a dependency could not be found, or the version could not be matched. It
would be nicer if describe JSON output could still be supplied, and
instead the dependency packages that could not be resolved would still
be presented in the 'packages' json, but would have some error field
detailing why they could not be presented.

Another example, is if DUB is going to download packages as part of dub
describe. There will be output like this:

The following changes will be performed:
Fetch tcltk >=8.5.11, userWide
Fetching tcltk 8.5.11...
Placing tcltk 8.5.11 to C:\Users\Bruno\AppData\Roaming\dub\packages...

etc., before the JSON output starts. Currently I workaround this in DDT
by only considering the dub-describe output until a '{' is found. This
workaround works well, so it's not an important limitation right now,
but it's worth keeping in mind for the future.
Not outputting those messages would 'fix' any potential parsing issues,
but it would deprive the user of any feedback, which would be worse than
the status quo I think. (Think of the case of large packages that may
take a while to download). Ideally, each fetch operation, or any
pre-requesite to dub-describe would be output as its own JSON document.
So as a rough example:

{
"operation" : "fetch",
"package" : "tcltk"
"version" : "8.5.11"
"user-message": "Fetching tcltk 8.5.11..."
}

until finally the final dub-describe JSON document would be output:

{
"operation" : "describe",
"name": // ... regular dub-describe output...

}

This last issue has small priority I think, but the issue about giving
error messages about failed dependency resolving in the JSON itself is a
bit more important and it would be cool to have that looked into.

Bruno Medeiros
https://twitter.com/brunodomedeiros