Make dub part of the standard dmd distribution

[Sönke Ludwig via Digitalmars-d]

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

Well, enforcing it on code.dlang.org would indeed be an option. I still 
think that using the version backed approach below, or VCS facilities is 
superior in general, though. There is not much objective reason to 
duplicate that functionality in the package manager AFAICS.

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

That's what dub.selections.json is for! It applies only to the top level 
project, which can make such decisions. On the other hand, if you always 
prefer the branch during *dependency resolution*, some deeply buried 
dependency can simply break your build (or any upstream build) because 
it chose to use an incompatible branch based dependency.

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

If you want commit granularity then that's a different thing. The 
intended way to support this is to still use version tags - DUB will 
then associate a branch with the latest matching version tag, so that 
normal version based dependencies can be used.

If that case applies, dub.selections.json will contain something like 
{"somedep": "1.0.0+commit.14.f23a56gb"}. Currently this information 
isn't used to drive GIT to fetch the right tag, but a ticket for that is 
open and this could be a viable middleground solution.

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

It's not really a workaround. The package manager has a version based 
dependency handling logic that has the proper semantics for this kind of 
task. Trying to squeeze branches and commits into this isn't necessarily 
a good idea or even necessary at all. The idea here is to let you do 
such things and not get in the way, but why should the package manager 
duplicate functionality of the VCS when that can solve the task just 
fine? It adds additional and redundant complexity for no real benefit.