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=?=
<schue...@gmx.net>":
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.
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?
There are only the following cases AFAICS, none of which require
an order:
1) Package is not yet in dub.selections.json:
=> Clone/update repo, checkout the branch, and put the exact
commit id into dub.selections.json.
2) Package is already included in dub.selections.json:
=> All fine, nothing needs to be done.
3) An upgrade of the package has been requested:
=> Same as 1)
There could be situations during dependency resolution where you
want to check whether a given commit is part of a branch, but
that's a different (and easier) problem.
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.
