Make dub part of the standard dmd distribution

[via Digitalmars-d]

On Thursday, 4 June 2015 at 13:47:41 UTC, Sönke Ludwig wrote:
> A branch *is* an exact version as far as DUB goes (just one 
> that changes over time).

Well, that's the problem then.

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

I'd say it's the only consistent way.

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

I can understand that. But from what I've seen with rubygems, it 
is not a problem in practice. You're totally right that released 
packages shouldn't have such dependencies. A warning message in 
dub or a check on code.dlang.org is totally okay IMO.

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

Definitely always prefer the branch. The goal is to let the 
developer override the decisions made by upstream library authors.

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

Yes, but that's a social problem. We can nudge people in the 
right direction by printing a warning message, or even by 
rejecting it completely on code.dlang.org.

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

I does have obvious drawbacks: If dub.selections.json contains 
non-exact versions, different developers can get slightly 
different dependencies. dub.selections.json must fully determine 
the versions that are going to be used, otherwise it has failed 
its purpose.

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

As explained above, it isn't.

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

Yes, and I'm sure I can come up with even more workarounds ;-)