Am 26.11.2015 um 21:41 schrieb Bruno Medeiros:
On 26/11/2015 16:10, Sönke Ludwig wrote:
The only valid reason for an IDE to directly parse the package
description is basically if it wants to provide a custom UI for editing
it. If the IDE is written in D, it can easily use DUB as a library and
not only get the package description in a common format, but also nicely
statically typed. If not, the conversion feature that was planned for
the next version would trivially solve that, too.
This is isn't true. There are things that an IDE might want to do, that
"dub describe" doesn't currently account for. The DDT IDE is an example
of that, and I've raised these issues before with DUB. For example:
* dub describe fails if dependency resolution fails, yet there is
still partial information about the DUB package that would be of use.
Good point. I'd say "dub describe" should simply fail gracefully and
just skip the "targets" and "dependencies" fields.
* dub describe does not provide information for all build
configurations, only the default one. As such the IDE has to parse the
json to find out all available configurations itself. (This is used in
the DDT IDE to show a list of "Build Targets" in the UI)
You can do "dub --print-builds --print-configs --annotate"
But it's currently uselessly bound to the build/run commands. Should
definitely be part of "dub describe"'s output.
