Add support for Go (dep)

[greysteil]

Currently just a starter pack. The following concerns need to be written:

• FileFetcher. This should be simple. Need to check for info about workspaces etc., though
• FileParser. Looks like lockfiles are just TOML, so this should be simple
• UpdateChecker. This will need to tap into dep and do resolution, but without doing an install. Hopefully that's possible...
• FileUpdater. Same deal as for the UpdateChecker
• MetadataFinder. Should be simple, as Go dependencies always specify a path

Note: In v1, vendoring is out of scope.

[greysteil]

@hmarr - looking at it, I think this might be relatively straightforward. Any gotchas lurking for me that I might not have considered?

[greysteil]

@hmarr - this is at the point where it could use a little attention from you.

• We're going to need to add Go to the Dockerfile, and sets the GOPATH to be the helper directory (I guess?) or somewhere sane
• For the UpdateChecker
  • A clever way to get the latest_version would be nice (without doing resolution). Can we tap into dep for that? Note that the version should be a SHA for dependencies that specify a branch or revision, and a numeric version for those that don't (the same as appears in the Gopkg.lock). There's a (very) crude way we could do this by making the same assumption we make in the MetadataFinder but it's ugly (basically using the dependencies name / source to check against our whitelist of known source code hosting providers)
  • We need to shell out to dep to get the latest resolvable version, or write some Go code that taps into its internals. I think that dep ensure -update -no-vendor might be our friend here, but we'll need to write a bunch of temporary files (manifest, lockfile, and something covering imports?) to get it working
• For the FileUpdater
  • Should be trivial once the UpdateChecker is done - using dep ensure -update -no-vendor should just work

What do you reckon?

[greysteil]

Another note: the inputs-digest in the lockfile is going to be a pain, because we don't want it to change if the Gopkg.toml hasn't, but do want it to change if it has. Getting it right will mean getting our dummy inputs file exactly right. Hopefully that can be done, but it's non-trivial (we can't tell whether all orphaned dependencies in the lockfile are imported somewhere or the children of dependencies that are imported somewhere).

Thankfully, the inputs-digest should be very quick to calculate, so we can iterate through all the possible dummy imports files to get the right one.

[greysteil]

Note: golang/dep#1912 is merged, so our life is going to get easier on inputs-digest. That's unreleased (will be in 0.5.0, which is coming soon).

[greysteil]

OK, this needs more tests, which I'll keep adding, but it's ready for testing in the wild.

[hairyhenderson]

🎉