preview: reorganize to work with go build

[lcowell]

We were talking about different build options for the cli, so I put together what the project would look like if we moved to go build (gb). I thought it would be useful to review and see if it's worth it to make the change.

You can see what I put together here:
https://github.com/lcowell/cli/tree/gb

Pros

• control of dependencies
• reproducible builds
• built in cross platform builds

Cons

• glitch doesn't work (yet)
• tying ourselves to a build tool early in the race
• more directory structure

We'd still need to update the install and build instructions as well as the release build process. I'm sure there's many other things to do.

You can build using:
gb build

Or build for other target using:
env GOOS=linux GOARCH=arm gb build

You can test using:
gb test

[Tonkpils]

What would be the downside of using Go's built in vendoring instead of relying on a third party? I know it's experimental but it'd be worth jumping on that so we can be ready when it's actually supported.

Also, as far as glitch and automatic build support. I, along with a buddy of mine, wrote a similar tool to glitch which allows automation of tasks https://github.com/Tonkpils/snag. You can give it a try and see if it's something worth using instead of glitch.

built in cross platform builds

I think you mean the same as what go 1.5 provides in terms of cross-platform builds?

[kytrinyx]

I've not actually been running glitch lately, and would be fine with swapping it out if it lets us simplify something else.

[lcowell]

The GO15VENDOREXPERIMENT="1" thing would actually work well. It seems like the smallest change for the biggest benefit

Any ideas on how to handle those dependencies from a git perspective? We could simply inline it or look at git-subtree or git-submodule.

[Tonkpils]

Any ideas on how to handle those dependencies from a git perspective? We could simply inline it or look at git-subtree or git-submodule.

Not sure I understand what you mean. I believe the dependencies would just get checked in to the repo as you would with godeps or gb.

[lcowell]

From what I've just read, using the git features I mentioned is not recommended. So yeah, we should just check in the dependencies to the project. It's not clear to me how we would update our dependencies without it being tedious, but maybe that's where a tool like gb (or something else) comes in.

I'd be happy to see this done, I know some of the trouble I had working with the cli when I first started was because I had a slightly older version of codegangsta/cli and the error message was not telling.

[Tonkpils]

We can look into it, with Godeps it was as simple as doing godep update my/package and it would update the necessary package in the Godeps folder and you would just commit it. I haven't looked too deep into go 1.5 vendoring but I'm sure it has something similar as does gb. Let me read a bit into it and i'll check back.

[Tonkpils]

I've vendored in dependencies using Godeps on #292 let me know what you all think

[Tonkpils]

Closing this, we've merged vendor support and it should work with the go tool on Go 1.6