4 ms·

(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. https://github.c

(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. https://github.com/golang/dep https://github.com/golang/dep

kminehart 9y ago
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.
aphextron 9y ago
>(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. I didn't realize they were working on solving this, that's fantastic. Hopefully it can gain traction.
- kminehart 9y ago
  github.com/golang/dep is actually an already fantastic (and official) solution.
naibafo 9y ago
First a note, godep is a different tool then the one you mean [1], that does the same. > dep still has nasty bugs, but in general these are comparable or fewer to other tools out there. (From the Github readme) I started a project about two months ago and wanted to use Dep, however there were a few show stopping issues for that. Most prominently Go has issues with upppercase/lowercase repositories, meaning if one of your dependencies imports github.com/Sirupsen/logrus, and you or another dependency imports github.com/sirupsen/logrus your code won't compile, no matter if you are on a case sensitive system or a case-insensitive system. [2] The aforementioned logger made a switch in the naming which caused problems while most were migrating the import. The docker distribution in its latest stable version still uses uppercase, while others use the lowercase. Dep follows the Go specifications and at the moment just throws an error, before, they didn't handle it at all. So I had to resort to a different dependency management for now, which did some linking to fix the situation. [1]https://github.com/tools/godep https://github.com/tools/godep [2]https://github.com/golang/dep/issues/1010 https://github.com/golang/dep/issues/1010
pebers 9y ago
AFAIK it's still not decided when/if it will join the main distribution. I've not tried it for a while now but last I saw it was even more opinionated about GOPATH than the existing tooling, and it wasn't at all easy to figure out what it wanted me to do. Maybe it's improved since though.

kminehart 9y ago

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.

aphextron 9y ago

>(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. I didn't realize they were working on solving this, that's fantastic. Hopefully it can gain traction.

kminehart 9y ago
github.com/golang/dep is actually an already fantastic (and official) solution.

naibafo 9y ago

First a note, godep is a different tool then the one you mean [1], that does the same. > dep still has nasty bugs, but in general these are comparable or fewer to other tools out there. (From the Github readme) I started a project about two months ago and wanted to use Dep, however there were a few show stopping issues for that. Most prominently Go has issues with upppercase/lowercase repositories, meaning if one of your dependencies imports github.com/Sirupsen/logrus, and you or another dependency imports github.com/sirupsen/logrus your code won't compile, no matter if you are on a case sensitive system or a case-insensitive system. [2] The aforementioned logger made a switch in the naming which caused problems while most were migrating the import. The docker distribution in its latest stable version still uses uppercase, while others use the lowercase. Dep follows the Go specifications and at the moment just throws an error, before, they didn't handle it at all. So I had to resort to a different dependency management for now, which did some linking to fix the situation. [1]https://github.com/tools/godep https://github.com/tools/godep [2]https://github.com/golang/dep/issues/1010 https://github.com/golang/dep/issues/1010

pebers 9y ago

AFAIK it's still not decided when/if it will join the main distribution. I've not tried it for a while now but last I saw it was even more opinionated about GOPATH than the existing tooling, and it wasn't at all easy to figure out what it wanted me to do. Maybe it's improved since though.