[mseepgood]

> But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get.

You obviously didn't vendor your dependencies in your project's vendor directory.

[CannisterFlux]

I found vendor directories to be documented in a confusing way, so I'm not surprised.

https://golang.org/cmd/go/#hdr-Vendor_Directories

I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.

[twblalock]

> You obviously didn't vendor your dependencies in your project's vendor directory.

You shouldn't have to!

A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.

[bigdubs]

Vendoring doesn't work outside $GOPATH

[mixedCase]

Don't work outside $GOPATH. Set a temporary one if you want a completely isolated environment for one-off building purposes.

[stouset]

Then what's even the point in the first place?

[mixedCase]

Development. Which is why I said "for one-off builds".

[icholy]

Why is this the case?

[Spiritus]

It didn't have any external dependencies, only multiple packages.

[0xdeadbeefbabe]

If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.

[_0w8t]

Even if one vendors the external dependencies, the code that uses them must still be on GOPATH or the compiler would not find them. This is at least with go 1.6.