go.mod is gigantic and causes problems to people trying to use it as a library.
Arguably Go’s tooling is also somewhat to blame: Go doesn’t make it easy (or even possible) to use a subset (a few packages) out of a mega module like gVisor without getting impacted by otherwise-unrelated requirements of that dependent module.
Specifically, Tailscale wanted to use gVisor’s
tcpip networking packages, which worked fine for a while, but then one day we bumped our gVisor version to pull in a bug fix we needed (from the networking-related part of gVisor), and that ended up making us pull in new conflicting versions of
etcd. Why? Because somewhere in that
go.mod Docker or
grpc or Kubernetes or whatever depended on etcd somehow. Who knows. We spent too long trying to fix it and gave up.
Our fix is this repo, pulling netstack out of gvisor like it used to be, with a small
We don’t accept contributions. This repo isn’t human-maintained. It’s synced from gVisor’s “go” branch. In fact, the flow looks like:
- humans maintain gVisor inside Google’s internal monorepo (let’s call it
- some scripts inside Google export
//googletree/gvisor/...out into GitHub occasionally
- oh, but
googletreeuses Bazel, not the
- so some other scripts rearrange the GitHub repo into the gVisor “go” branch (https://github.com/google/gvisor/#using-go-get)
- some of our scripts then take that “go” rearrangement tree and delete all the Linux and Docker and container stuff, leaving behind only the networking stuff
Same as gVisor.