3 ms·

It is certainly a fantastic solution, and I definitely appreciate the work that Sam Boyer and the `dep` contributors do. There's a lot of "gotya"s with using d

It is certainly a fantastic solution, and I definitely appreciate the work that Sam Boyer and the `dep` contributors do. There's a lot of "gotya"s with using dep though. One that gets me a lot is the fact that I like to commit my vendor folder, just for faster CI. So if I committed my vendor folder with a copy of "k8s.io/client-go", and then in a different project I imported a package from my vendored project, it would never compile until I removed my local copy of that "vendor" folder, since it's looking for that specific dependency ("my-project/vendor/k8s.io/client-go"). Not sure if I explained that super well.

infogulch 9y ago
Ok, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.
- KishanB 9y ago
  I personally like glide more than godep
- kminehart 9y ago
  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

Ok, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.

KishanB 9y ago
I personally like glide more than godep
kminehart 9y ago
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.