DUB release candidate 0.9.24-rc.3 ready for testing

[Sönke Ludwig via Digitalmars-d]

Am 18.09.2015 um 10:37 schrieb BBasile:
> On Monday, 14 September 2015 at 11:45:13 UTC, Sönke Ludwig wrote:
>> If no regressions show up in this RC, the final release will be made
>> on the upcoming Sunday. The main additions are support for SDLang [1]
>> package recipes [2] and a vastly improved "dub describe".
>>
>> Download:
>> http://code.dlang.org/download
>>
>> Change log:
>> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>>
>> [1]: http://sdl.ikayzo.org/display/SDL/Home
>> [2]: http://code.dlang.org/package-format?lang=sdl
>
> I find that the feature to get a particular property (`--data=X`) is
> very slow, is it normal ? On a decently recent machine it takes
> something like 3 or 4 seconds. Maybe it downloads or check the deps
> while it's not necessary ?

In the context of an IDE, I'd strongly recommend to use the normal "dub 
describe" functionality. The "packages" field will list the logical 
packages, suitable for display in the IDE's project tree and the 
"targets" field will contain the list of binary targets, suitable as the 
input for external build tools. All of this comes at once with a single 
process invocation.

The --data= functionality is more useful for shell scripts and the like, 
where data is needed in condensed form. I'm also pretty sure that there 
are still some issues to work out in the way the --data switch works, 
because in its current form it simply cannot represent everything. So 
I'd label this feature as experimental for now.

There are some things that may take time during a DUB run:
  - Determining the versions of local GIT working copies that are 
registered with "add-path" or "add-local". "git" is invoked for that for 
each working copy, which simply takes time if there are many of those 
registered. I'm currently looking into a version cache feature that 
would make this faster.
  - Querying code.dlang.org for new package versions to display upgrade 
suggestions. This takes a moment, but is only done at most once a day.
  - Resolving dependencies currently suffers from a performance bug that 
can cause the resolution time to grow almost indefinitely.

To see which of those is responsible, running with the -v switch may 
give some insights.