RejectedSoftware Forums

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?

On Wed, 05 Mar 2014 16:19:46 +0000, Bruno Medeiros wrote:

On 26/02/2014 16:39, Sönke Ludwig wrote:

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?

That's exactly my idea, and yes, it would be easier to parse a single
document at a time. But this is very low priority for me, TBH with all
the more important stuff there is to be done, I'd be surprised this will
ever get touched.
Currently DDT parses dub.json and presents a raw (unresolved) import
path and dependencies in the UI and the starts 'dub describe'. When that
finishes, the resolved import path and deps is presented in the UI. The
user can see in the 'dub describe' console that fetch is on-going so I
think the status quo is even better than a "operations" field, as that
is less readable for the user in the console. So it's good, as long as
there is no '{' before the JSON document starts!

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?

Maybe that's a simpler solution. Maybe have 'dub describe --fetchOnly',
which would give a different json document stating the required fetch
operations, and then start the fetch.

Bruno Medeiros
https://twitter.com/brunodomedeiros

Okay, I've created a ticket for this with the plan to implement it for 0.9.22.