Make dub part of the standard dmd distribution

[via Digitalmars-d]

On Thursday, 4 June 2015 at 08:51:02 UTC, Sönke Ludwig wrote:
> Am 01.06.2015 um 17:16 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= 
> <schuetzm at gmx.net>":
>> Since this thread seems to have turned into a wishlist for dub 
>> features,
>> I'm going to add one:
>>
>> Undeprecate dependencies on git branches. They are really not 
>> different
>> from dependencies with fuzzy "~>" versions. For both, the 
>> exact selected
>> version can be stored in dub.selections.json.
>>
>> Use case:
>> Making a fix to a third-party project and sharing that fix 
>> with other
>> team members. Having to create a temporary project on 
>> code.dlang.org
>> just for that purpose is both a waste of time for developers 
>> and a waste
>> of resources of community infrastructure.
>
> They are only deprecated within dub.json. You can still use 
> them within dub.selections.json.

This is exactly the wrong way round. dub.selections.json must 
only contain exact versions. That's its purpose after all.

See Ruby's bundler as an example:
http://bundler.io/v1.9/rationale.html
Especially the parts about Gemfile.lock, which is their 
equivalent of dub.selections.json.

> But really, branch based dependencies are simply a broken 
> feature. They are completely different to version ranges, 
> because they are not at all comparable (to other branches or 
> versions) - at least without completely committing to GIT and 
> starting to walk the GIT commit graph.

Why would you even want to compare them, except for equality? 
There are only the following cases AFAICS, none of which require 
an order:

1) Package is not yet in dub.selections.json:
=> Clone/update repo, checkout the branch, and put the exact 
commit id into dub.selections.json.
2) Package is already included in dub.selections.json:
=> All fine, nothing needs to be done.
3) An upgrade of the package has been requested:
=> Same as 1)

There could be situations during dependency resolution where you 
want to check whether a given commit is part of a branch, but 
that's a different (and easier) problem.

>
> You can also check out certain branches locally and use "dub 
> add-local" or "dub add-path" to let DUB use it instead of the 
> publicly registered one.

This is not an option in a larger team. Everyone would have to do 
that manually, or you'd need to write a custom script to do what 
is actually the package manager's task.