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