[lobster_johnson]

If anything, the Go people have repeatedly claimed they don't know best -- because Google famously uses a huge monorepo with all deps vendored, and don't do "package management" as such -- and have preferred to let the community find a solution organically.

Which is also why we ended up in this frustrating profusion of competing tools (Godeps, Glide and many others, plus the messy business that is git submodules) rather than a concerted effort towards a unified solution.

I don't at all believe the argument that they can't design something because they don't need it at Google. They're engineers, after all. You don't need to use a bridge in order to build one. There are plenty of existing tools (Bundler, Cargo, NPM, Cabal) that can also be used as case studies in how to do things right (Bundler, Cargo) or don't do them wrong (NPM).

In my company we use Glide, which is the best solution I've encountered so far, but it's beyond buggy, and struggles with some Google repos that need to be flattened in order to avoid duplicate, conflicting dependencies (glog and pflags, sigh).

[cyphar]

> If anything, the Go people have repeatedly claimed they don't know best

So why is the defacto vendoring system for the Go tooling incompatible with old Go versions (the "organic" solutions were compatible with Go versions without vendoring support because they were implemented before vendoring support was a thing!)?

The vendor/src hack meant that you could compile with ANY version of Go -- that's important for distributions (and other people who want to build runC and Docker -- put plainly we pin Go versions because of compiler bugs). But no, now we have to use vendor/ which means that now we have to do even more messing around with the GOPATH (which makes rpmbuild even more ugly than it needs to be). sigh

[lobster_johnson]

I can't explain that since I'm not on the Go team. However, it's possible that they also didn't realize this hack was being relied on by people. The fact that you describe it as a hack implies it was never intentionally supported behaviour. Did you bring it up during the development of 1.5?

[cyphar]

> The fact that you describe it as a hack implies it was never intentionally supported behaviour.

It's used by the largest Go projects that exist. So if the Go developers didn't look at what the largest Go projects do and take inspiration from that, I'm really not sure what else to say.

A hack that is used by everyone is relied upon behaviour. I wouldn't even call it a hack, it's trying to make Go's obsession with your filesystem actually usable -- why on earth does my compiler toolchain care about how my home directory is structured?

The old method still works, you just have to call the directory something other than vendor/. Which just defeats the whole point.

> Did you bring it up during the development of 1.5?

My experience with Go 1.5 was a lot of other (more serious) bugs, so I didn't have a chance to comment on that particular issue. I'm surprised nobody from Docker said anything though.