x/build: migrate to using Go modules

[bcmills]

On https://golang.org/cl/128636, @bradfitz notes:

I'd want to understand what we do & don't use [modules] for […].

For example, all of our "make deploy-prod" etc scripts right now build in a Docker container with an entirely different mechanism.

Initially, I think we should start with exactly what we're doing today, but with the ability to make changes in x/build with a known-reasonable set of dependencies. That's https://golang.org/cl/128636.

There are certainly more interesting steps we can take down the road: for example, we might be able to use go mod download in place of cmd/gitlock to wire in dependencies.

This issue is for tracking those steps.

[gopherbot]

Change https://golang.org/cl/128636 mentions this issue: all: add module definitions

[bcmills]

@FiloSottile notes: “there’s stuff in vendor/ that disagrees with the go.mod, we should fix that if we’re going all in on modules”

[bcmills]

(I'm guessing he's referring to the stuff in vendor/github.com/tarm/serial.)

[dmitshur]

(I'm guessing he's referring to the stuff in vendor/github.com/tarm/serial.)

There's also https://golang.org/cl/129075, those 2 commands must be out of sync too by now.

Edit: Whoops, that's not related to stuff in vendor/, but rather a Dockerfile. Sorry.

[bradfitz]

I think it's time to delete gitlock.

I've been using modules for my own projects for some time and prefer it over gitlock. (which was always meant as a medium-term solution)

/cc @dmitshur

[dmitshur]

Well, given this is x/build and its policy (which I can't find for some reason right now), we can experiment with modules as long as they work for our needs. See https://go-review.googlesource.com/c/build/+/128636/#message-82cc0747061a265a95ab44a9ef7debe6798a4392.

I'm in favor of using modules to build commands reproducibly for deployment (aka, replace what gitlock is used for now). 👍

As long as that doesn't interfere with keeping the libraries in this repo (e.g., maintner) working in the GOPATH world.

[bradfitz]

First speed bump:

bradfitz@gdev:~/src/golang.org/x/build/cmd/gopherbot$ GO111MODULE=on go mod init

bradfitz@gdev:~/src/golang.org/x/build/cmd/gopherbot$ GO111MODULE=on go list -json .
.....
can't load package: package golang.org/x/build/cmd/gopherbot: unknown import path "golang.org/x/build/cmd/gopherbot": ambiguous import: found golang.org/x/build/cmd/gopherbot in multiple modules:
        golang.org/x/build/cmd/gopherbot (/home/bradfitz/src/golang.org/x/build/cmd/gopherbot)
        golang.org/x/build v0.0.0-20181108190521-5df336cd7fdc (/home/bradfitz/pkg/mod/golang.org/x/build@v0.0.0-20181108190521-5df336cd7fdc/cmd/gopherbot)

I suppose we could have one go.mod for all things in x/build but I'd prefer that each package main tool have its own, so we can bump dependencies independently as we deploy things.

Otherwise we'll be in a state where source code doesn't match deployed reality and we we'll bump go.mod deps affecting a dozen binaries and only deploy one of them, and have a few that haven't been deployed for years with untested deps.

What do I need to do to get past that error above, @bcmills?