[cyphar]

The one thing that really pisses me off about the way Go handled vendoring is that they did it in a way that makes it incompatible with GOPATH. Previously in runC and Docker, we had build hacks that would symlink (or full copy) the current directory into vendor/src/<package> and then set the GOPATH to vendor/. This was compatible with every go version. In addition, many other projects did the exact same thing.

But the way that vendoring works in Go 1.5 and up is that you make vendor not a valid GOPATH and you have to now either create a fake GOPATH and move your current directory into it, or you have to do some symlink stuff within vendor/ that doesn't really work. Why was such a small cosmetic change seen as a good idea? It's needlessly incompatible with previous ways of making vendoring work seamlessly with Go.

I'm hoping that the packaging discussions that are going to be happening over the next few months don't result in a similar decision that "we know best".

[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.

[zzzcpan]

> I'm hoping that the packaging discussions that are going to be happening over the next few months don't result in a similar decision that "we know best".

Judging by current packaging discussions, I don't see it happening any other way. I just hope they don't mess things up too much.

[hacknat]

I just wish they would add tagging support.