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