Make dub part of the standard dmd distribution

[Sönke Ludwig via Digitalmars-d]

Am 04.06.2015 um 12:30 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm at gmx.net>":
> 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.

A branch *is* an exact version as far as DUB goes (just one that changes 
over time). But to make use of any commit relationships within a branch, 
it would have to gain specific knowledge of GIT or other version 
management systems.

Adding support for commit hashes in dub.selections.json is still TBD, 
but would be another alternative.

BTW, my primary concern with all of these things is retaining a healthy 
public package eco system. I personally suspect that this is much more 
important for the language as a whole rather than pleasing every single 
taste. This doesn't mean that the latter isn't a worthwhile goal, but to 
me the former has always been more important. What is missing is a 
proposal how to solve both issues at the same time.

>
> 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? (...)

For example for conflict resolution. This is the foremost reason why the 
*have* to be banned from dub.json. You can't really know if a branch 
matches/is compatible with any particular version (range) or another 
branch, so you have to either make an arbitrary guess (always prefer the 
branch; always prefer the version; always prefer "master", but a tagged 
version otherwise; etc.), or always issue a version conflict error.

The practical effect that was already very visible in the existing 
ecosystem was that packages tended to separate into two clusters. One 
cluster that used branch dependencies and another that used version 
dependencies. Both incompatible with each other. It also meant that a 
lot of people didn't bother to make any version tags at all, which is 
understandable, but also a very bad influence to the stability of the 
ecosystem. Semantic versioning, if used correctly, is a very important 
factor in that regard.

The compromise solution to allow branch based dependencies only in the 
version selection file doesn't really have drawbacks, but dodges all of 
those issues by moving the decision to the root of the dependency tree.

>
>>
>> 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.

Using dub.selections.json should be the right tool then. You could of 
course also use things like git submodules + path based dependencies in 
this case, there is no need to force everything into one schema 
(especially when it doesn't fit well, such as versions and branches).