4 ms·

> 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

• bigdubs 10y ago
  Vendoring doesn't work outside $GOPATH
  • icholy 10y ago
    Why is this the case?
  • mixedCase 10y ago
    Don't work outside $GOPATH. Set a temporary one if you want a completely isolated environment for one-off building purposes.
    • stouset 10y ago
      Then what's even the point in the first place?
      • mixedCase 10y ago
        Development. Which is why I said "for one-off builds".
• Spiritus 10y ago
  It didn't have any external dependencies, only multiple packages.
• CannisterFlux 10y ago
  I found vendor directories to be documented in a confusing way, so I'm not surprised. https://golang.org/cmd/go/#hdr-Vendor_Directories 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.
• 0xdeadbeefbabe 10y ago
  If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.
• twblalock 10y ago
  > 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.
• fpoling 10y ago
  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.