Choose and implement vendoring solution

[Tonkpils]

Hopefully something that will allow using Go's vendoring but if there's other options then I'm open for it.

[zabawaba99]

Different package management tools that support the vendor directory https://github.com/golang/go/wiki/PackageManagementTools

[zabawaba99]

@Tonkpils I created two PR that both use Godeps differently.

57 uses the GO15VENDOREXPERIMENT environment variable along with the vendor/ directory.

• Pros:
  • We don't need anything special to build the project, just the Go tool
  • There are many tools that support vendoring into this directory.
• Cons:
  • Does not work unless you explicitly set an environment var
  • We can't just use the ./... notation (ref)
  • We can't build with go1.4 anymore

58 Uses pure godeps

• Pros:
  • We have the luxury of using ./... when building, testing, linting.
  • We don't have to remember to set an environment variable to build/test or update dependencies
  • Still works with go1.4
• Cons
  • We have to install an additional tool when building on travis

After looking at both PRs, my preference would be to go with #58 .

[Tonkpils]

I'm actually for #57 the reasons are mostly looking forward:

Cons: Does not work unless you explicitly set an environment var We can't just use the ./... notation (ref) We can't build with go1.4 anymore

• The environment variable is actually going away and it will be the default for go 1.6
• There's a bit of a workaround using go test $(go list ./... | grep -v /vendor/)
• Do we care to build with 1.4 anyway? This is only relevant in development and we're already in 1.5. I don't see us going back versions but rather forward.

I'm taking a look at both PRs now and I'll check back here with my update once I see the actual code.

[zabawaba99]

I'm ok with going with #57.

• The go1.6 release is around the corner anyway.
• The go list bit is a MUCH better way to list the packages :+1:.
• I would say no, and agree with you. Was mentioning more since it was in our travis.yml.

I preferred #58 more for personal reasons in having to manage the environment variable ;). I'll close that PR for now and continue to polish #57 .