Am 19.09.2015 um 12:10 schrieb Jacob Carlborg:

I'm finding it a bit hard to understand how "dub add-local" works or
rather why it works like it does. What I don't understand is why
packages added with "dub add-local" have priory over packages in the Dub
registry.

Let me explain what I'm trying to do. I'm trying to figure out a good
workflow for working with multiple dub packages without pushing anything.

Say I have two projects A and B. B is a dependency of A. I want to make
some changes in A which also requires changes in B. Of course I would
like to make the changes both in A and B before pushing the changes in B.

So I tried using "dub add-local" for the path to project B. Then I
compiled A and to my surprise it picked up the changes in B. The
surprise is that I didn't have to change anything at all in dub.json.
That would suggest that all other packages that depend on B will have
this change as well, which I absolutely don't want to happen.

So why this behavior?

I much rather prefer how Bundler works in the Ruby world. Gemfile
contains the dependencies:

Gemfile for A

gem 'B', '1.2.3'

Now I would like to make some changes to B without creating a new
version of B or push anything. I then just change the file to:

gem 'B', path: /path/to/B

This doesn't require me to release a new version of the gem, push
anything or not even commit my changes. The best of all, it's only
project A that uses these specific changes to B.

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.

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"}

BTW, how to I find out which packages have been added with "dub
add-local"? I tried "dub list" which list all packages regardless if
they where added with "dub add-local" or not. "dub list-overrides"
doesn't print anything.

"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?

On Mon, 28 Sep 2015 09:37:10 GMT, Jacob Carlborg wrote:

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.

Yes right, that approach basically only works as long as you don't make changes in C that break other project that you are actively working on (until you make another version tag). For me this works out 99% of the time and I never have to temporarily adjust my selections files, which saves time. But of course different people have different habits and this doesn't apply to everyone. I think the different approaches need to be mentioned in a document somewhere.

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.

Added a ticket: #705