Join GitHub today
x/build: migrate to using Go modules #26872
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
This issue is for tracking those steps.
pushed a commit
Aug 8, 2018
referenced this issue
Aug 16, 2018
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
As long as that doesn't interfere with keeping the libraries in this repo (e.g.,
First speed bump:
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?
If you're splitting out a submodule, the new submodule needs to depend on a version of the parent that does not contain the newly-split packages.
If you want to actually test that change, you'll probably need a