3 ms·

I think you misunderstand. If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder.

I think you misunderstand. If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder. Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this: pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as type "github.com/project/a/vendor/github.com/dependency/pkg".Example It's not a big deal because if I just remove "github.com/project/a/vendor" from my $GOPATH then the problem is resolved. because of this, I guess my real complaint here is that "vendor" doesn't seem to be the right word. I'm really just looking for something to complain about.

infogulch 9y ago
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. Could that work?
- kminehart 9y ago
  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".
  - infogulch 9y ago
    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.

infogulch 9y ago

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. Could that work?

kminehart 9y ago
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".
- infogulch 9y ago
  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.