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