Am 04.06.2015 um 12:30 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?=
<[email protected]>":
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=?=
<[email protected]>":
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).
