5 ms·
> how they like vendoring in Go Vendoring solves sharing dependencies with your team, it does not solve the addition of new dependencies. You still need to get
by bbatha 9y ago
> how they like vendoring in Go
Vendoring solves sharing dependencies with your team, it does not solve the addition of new dependencies. You still need to get your dependencies somehow, and they need to be able to specify what dependencies they work with. And your libraries can't vendor their libraries in go because then they'll have a different import path in vendor directory and in the main project and you won't be able to share types.
- bigdubs 9y ago1. Minimize dependencies. Much of the problems w/ dependency management have to do with over-coupling and adding lots of random dependencies for things you could just inline into your project. Also why the stdlib is so strong. 2. You can pick specific versions and follow basic semver constraints if you want by checking out the source for the dependency locally, and then copying to vendor. Automatic resolution would be nice but it's not like you can't do it. 3. Better automatic dependency management is coming. But honestly I prefer it to be arduous to add an external dependency. You should only do it if you absolutely need to. The bit about import paths being wrong I've generally not found to be the case; the go compiler will treat deps with the same in vendor or in gopath.
- laumars 9y agoYeah I know; I wasn't trying to make an argument in favour of Go's vendoring. My point was far more meta than that :)