Oh I see. I think the conventional wisdom here is to only ever vendor the end use (binary) projects, not libraries (and maintain such a distinction). (But I guess that's as helpful as "you're holding it wrong".)
So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is wrong for B.
I would fix it by moving A's main into A/cmd, and vendor at A/cmd/vendor instead. A/cmd can still import all its' helper packages like before, but now B can also import them without getting snagged by A's vendoring because it vendors another level up.
Hmm yeah I think that would be a good option. One potential problem with that is running tests on the individual packages. I believe that the vendor folder would have to be in a descendant folder. So like... "./vendor", or "../vendor", "../../vendor", and so on. If the vendor folder was in "./cmd/vendor", and you ran the test "go test ./pkg/example", it would not find the vendor folder.
My solution was just to not commit the vendor folder, and before the test starts, run "dep ensure".
Oh that's certainly a good point and a deficiency in my design.
But then again if you're only testing H against A's vendored dependencies specifically, you're missing testing it against B's. I'm not sure how you would fix that.
So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is wrong for B.
I would fix it by moving A's main into A/cmd, and vendor at A/cmd/vendor instead. A/cmd can still import all its' helper packages like before, but now B can also import them without getting snagged by A's vendoring because it vendors another level up.
Could that work?