Am 25.02.2014 19:11, schrieb Bruno Medeiros:

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.

I'll put this on the list for the next release. It will be interesting
to see how to intercept the logger in the most elegant way, but this
surely has to be fixed somehow. Regarding the last suggestion, for
backwards compatibility reasons and to keep a single document, I'd opt for 

{
   "operations": [
     {"type": "fetch", "package": "tcltk", ...}
   ],
   /* regular dub describe output */
}

Or was your idea to be able to display the operations in real time in
the GUI and it would be easier to parse a single document at a time?
Maybe it would be a good idea to add a more interactive mode to handle
fetch operations and the like, or at least to keep it a strictly
separate operation?