3 ms·

Sorry, maybe this is a stupid question... but does this require me to store all the dependencies under ./vendor in the repo? I would really prefer it ./vendor

Sorry, maybe this is a stupid question... but does this require me to store all the dependencies under ./vendor in the repo? I would really prefer it ./vendor would be .gitignored (like .virtualenv or node_modules) and `make deps` would parse the source and fetch the deps, sort of like `go get` does. Bundling all the dependencies in your own repo just feels wrong to me. Especially if it's not git submodules (and I've heard submodules are frowned upon by those who have tried them - I've haven't had such necessity, so don't hold any opinion). At least very similar approaches had led to some really bad experiences I had in early 2000's with PHP (it was typical to bundle vendored deps there because of relative lack of package management).

FiloSottile 10y ago
That depends on the tool you want to use to manage your vendor folder, so no, hellogopher does not enforce an opinion on that. For example, you could modify the Makefile to run "gvt restore" before building. However, I warmly recommend checking vendor/ in: not doing so requires the user to have gvt (or whatever tool), breaks go get, and adds unnecessary external dependencies (think left-pad). More details here https://github.com/FiloSottile/gvt#alternative-not-checking-in-vendored-source https://github.com/FiloSottile/gvt#alternative-not-checking-...
- drdaeman 10y ago
  I see. Guess, bare `go get` just can't get a dependency into `./vendor/` so either a third-party or checking in is required. Is there any suggestions/best practices how to maintain `vendor/` under the source control? I mean, handling updates, branch merges and all the disaster that accidental local patches may bring - this sort of stuff?
  - TheDong 10y ago
    The real problem with go get here is that it can't pick a version, only latest. Checking in vendor is much safer because your dependencies can't break you. there are no good upstream suggestions on how to deal with vendor. My preference is to use to use http://glide.sh/ http://glide.sh/ and store 'glide.yaml' and 'glide.lock' in the repo, at which point the vendor folder can be recreated to the correct versions without needing to parse code or checkin vendor. Glide is also really good at handling updates, pulling from alternate sources, tracking alternate branch names, etc etc.

FiloSottile 10y ago

That depends on the tool you want to use to manage your vendor folder, so no, hellogopher does not enforce an opinion on that. For example, you could modify the Makefile to run "gvt restore" before building. However, I warmly recommend checking vendor/ in: not doing so requires the user to have gvt (or whatever tool), breaks go get, and adds unnecessary external dependencies (think left-pad). More details here https://github.com/FiloSottile/gvt#alternative-not-checking-in-vendored-source https://github.com/FiloSottile/gvt#alternative-not-checking-...

drdaeman 10y ago
I see. Guess, bare `go get` just can't get a dependency into `./vendor/` so either a third-party or checking in is required. Is there any suggestions/best practices how to maintain `vendor/` under the source control? I mean, handling updates, branch merges and all the disaster that accidental local patches may bring - this sort of stuff?
- TheDong 10y ago
  The real problem with go get here is that it can't pick a version, only latest. Checking in vendor is much safer because your dependencies can't break you. there are no good upstream suggestions on how to deal with vendor. My preference is to use to use http://glide.sh/ http://glide.sh/ and store 'glide.yaml' and 'glide.lock' in the repo, at which point the vendor folder can be recreated to the correct versions without needing to parse code or checkin vendor. Glide is also really good at handling updates, pulling from alternate sources, tracking alternate branch names, etc etc.