On Sun, 27 Sep 2015 20:58:56 +0200, Sönke Ludwig wrote:

Others projects will only get the changes if they also check out the
changes and use add-local on this working copy. The idea is that
people are either on the same development team, in which case it is
likely that they all want to see those changes, or that the dependency
is downloaded from a registry, in which case the actually tagged commit
will be used.

Not sure I understand.

  1. I have three projects A, B and C. All of them use Dub and are cloned locally. A and C depends on B

  2. I make some changes in B

  3. I use "add-local" on the path to B because I need the changes in A

  4. I run "dub" in project C's directory without making any changes. The changes in B are picked up because "add-local" overrides

It's step four that feels very weird to me. I would expect that I need to change dub.json or dub.selections.json to opt-in for Dub to pick up the local path. Or perhaps it's just me that don't understand the use case.

If you want to use Bundler's workflow, you could simply skip using
add-local and put this in dub.selections.json: 

 "B": {"path": "/path/to/B"}

Oh, I had no idea that you could do that. Nice :)

"dub list" is indeed currently the only way, you'd have to look at the
path and skip everything after the first ~/.dub/packages/... entry.
Alternatively, ~/.dub/packages/local-packages.json contains the list
of "add-path" and "add-local" entries. Maybe there should be a switch
for this for dub list? Or maybe just print the three classes of
packages as separate paragraphs, each with its own heading?

Yeah, a switch would be nice. I feel it's specially important when it overrides a non-local path by default. I might be using a local path without knowing it.

/Jacob Carlborg