Consider using godep for managing dependencies?

[justenwalker]

Godep is pretty much the de-facto tool for managing dependencies in go projects. I suggest we consider using Godep instead of manually checking out and manipulating the source repositories.

This requires that the directory structure be altered to conform more closely with the golang coding standards

[tgross]

I've talked about this notion at length elsewhere but I think the Go community has their dependency management story wrong. A lot of this is because the core team works in a mono-repo environment, and lots of the community is coming from development communities where breaking simple monolithic applications down into a hundred tiny sublibraries (none of which are useful on their own) is considered best practice and where the dependency story is even worse.

Also, I'm not sure I agree that Godep is the de-facto complete solution at this point either. The Golang development team has introduced the "vendor experiment" and it's almost certainly going to be the case that this is adopted as the standard. Godeps doesn't currently match up with this very well.

What's the value proposition for making this change?

[justenwalker]

Mostly this came out of my inability to get my tooling to detect the libraries required for using autocompletion. Conforming to go's conventions seem to alleviate this for most tooling.

I agree golang's dependency story is pretty bad, but it does seem that godep is used most often (a close second to using nothing). Vendor experiment is that - an experiment; however, godep supports this if you set an environment variable.

One use case is that I can run godep restore from the repository and my GOPATH will get all of the required libraries at their versions defined in Godeps.json - which allows my tooling (right now Atom Editor + go-plus) to find all the necessary libraries - in other words; no need to manually git clone <repo> && git checkout <ref> each dependency.

However; I concede that this proposal doesn't add much intrinsic value to the project or its users:

• It's a binary, not a library - so no one should be importing it into their own projects (yet?)
• It only really helps my workflow, but most likely doesn't help everyone (unless you're using atom + go-plus)

[tgross]

As much as I'm skeptical of the official golang approach, realistically I'm can't oppose the idea of trying to bring things in-line with the community if it reduces friction for contributing. But it does look like Go 1.6 has accepted the vendor experiment:

Go 1.6 keeps the vendoring support, no longer considered experimental, and enables it by default.

So we should probably rework #77 to support that model.

[justenwalker]

I'm can't oppose the idea of trying to bring things in-line with the community if it reduces friction for contributing.

@tgross, Do you agree with the proposed directory structure change? Namely putting a main.go shim at the top in the main package, and then putting all of the real code in the containerbuddy package

So we should probably rework #77 to support that model.

I'll look into getting this supported in place of the Godeps/_workspace model

[tgross]

Do you agree with the proposed directory structure change?

Yeah, that's fine.

[tgross]

Released in https://github.com/joyent/containerbuddy/releases/tag/0.1.3, which I'm hoping to be our final RC.