x/*: define module boundaries for all the repos under golang.org/x/

[dmitris]

@bradfitz -2'ed https://go-review.googlesource.com/c/net/+/141237 with the comment:

Temporary -2 until there's a plan somewhere and linked from here.
I suspect x/net is too broad for one blanket module.

This would be similar to #27858 (which is for x/tools).

It would be great to define the boundaries and set up modules (and tag the code so that it could be used with versions not looking like golang.org/x/net v0.0.0-20181005035420-146acd28ed58 😄

@bcmills - do you know if someone is already working on setting up modules in x/net? if so, could you please include them?

[bcmills]

To summarize the core issues from #27858, the main question to answer here is:

• Do the packages in x/net vary in terms of stability, or are they all v0 (unstable), or all v1 (stable)?

(I don't know the answer. CC @mikioh, @bradfitz, @ianlancetaylor, and @tombergan for their opinion.)

[bcmills]

Also as noted in #27858 (comment), an existing repository is (de facto) currently a single module: people can already define a go.mod file that refers to it at a particular commit, and if they run go get -u they will expect to have the same packages available.

So I think there's essentially no harm in defining the whole repo as a single module for now.

[bradfitz]

@bcmills, that is incredibly sad. I was hoping modules would get us out of this mess and let us carve up x/net and x/tools and let them have their own CI columns, etc. For instance, I'd love it if x/tools/cmd/guru breakages (it breaks all the time) didn't interrupt development of cmd/godoc. And x/net/html has nothing to do with x/net/http2, etc.

[rsc]

There needs to be a development of a plan for all the x repos, not a different plan for every repo. I think we should close all these "define module boundaries for one repo at a time" bugs.

[dmitris]

@rsc - I renamed the issue to "x/*: define module boundaries for all the repos under golang.org/x/", would it work? If not, feel free to close it.

[bcmills]

There needs to be a development of a plan for all the x repos, not a different plan for every repo.

@rsc and I discussed a general strategy for the x/ repos this morning.
My proposal (at least for the 1.13 cycle) is:

• Create a go.mod file at the root of each x/ repo, possibly after cleaning up extraneous dependencies (x/tools: clean up dependencies #29981, x/build: reconsider the large number of third-party dependencies #29935).
  • Before adding a go.mod file, ensure that the x/ repo is not required at its incorrect github.com/golang module path by any modules that are in the build list of said x/ repo. You can follow the steps described here to check this. This is to avoid regressions such as Unexpected module path lint#436.
• Maintain each go.mod file using go mod tidy. Specifically:
  • Include all of the dependencies produced by go mod tidy in the go.mod file.
  • Encourage the use of go mod tidy when imports are added or removed.
• If a specific CL needs to use a new feature or avoid an old bug, it's ok to bump the version of relevant dependencies in the same CL.
• It's ok to occasionally run go get -u to upgrade dependencies explicitly, but if the upgrade isn't relevant to a specific other CL, please send it separately. (https://golang.org/cl/145857 is an example of such a change.)
  • If the upgrade requires any code fixes, such as to work around incompatible changes, send those fixes in the same CL.
• Do not tag explicit releases yet, with the possible exception of x/text (which already has some version tags).
• We can revise this strategy as we learn what pain points arise.