According to https://research.swtch.com/vgo-tour
vgo vendor generates a vendor directory, however by default vgo will not use it for building.
To do that you would have to do a replace e.g. replace "rsc.io/quote" v1.5.2 => "../quote"

From the proposal, it seems that the vendor directory is currently included for backwards-compatibility, but it's not intended to be part of vgo's design.

The replacing workflow looks like a way to address the issue of necessary hot-patches to upstream code. That's another important benefit of our current vendoring workflow, so I'm glad that vgo supports something analogous as well!

But I don't think that's a solution here. From the post, it seems like the assumption is that ../quote would either use a separate repository for version control, or that both would be versioned by the same repository whose root is the parent (or an ancestor) of both. Neither seems ideal. The former means we'd have to create a separate, internal fork of every dependency that we import, which is cumbersome and unwieldy. The latter means that we'd have to fundamentally change the structure of all the Go projects we develop, which would be a huge upheaval - it sounds like it'd essentially mean that each project's repository vendors its entire GOPATH (excluding the standard library) at the top-level, instead of containing the vendored code within the vendor directory. That'd get confusing and hard to manage very quickly.

It also means that, every time we want to update a dependency, we'd have to update it in two steps, not one - we'd first have to update our internal fork (whether in the same repository as our main project or a different one) and then we'd have to update the minimal version specified in go.mod.

The two-step update process adds friction, which is key to the second scenario described in the blog post above (preventing people from accidentally reintroducing known regressions). In that scenario, adding friction is the desired outcome, but I don't think we want to impose the same level of friction every time we update a dependency.

First, let me +1 the point that having to set up services is a significant barrier to adoption in companies. I worked for one of the biggest Go shops in a sense, and even there having to set up a service, getting it on the right networks for both developers and CI, and maintaining it, would have been a problem and friction.

Second, it looks to me like a file:// GOPROXY solves, if inelegantly, the problem. There's probably tooling we can build to make that work better, for example a simple tool to build the directory. If stored inside, say, vendor/_vgo it would also be excluded from the module builds. Maybe vgo could even look there by default for cached modules.

I, too, am a fan of self-contained projects. In a way they are the static binaries of source trees.

@FiloSottile to make sure I understand: in that case, the file:// directive would go inside the go.mod? So that means that the choice to use local copies of the file has to be made on a per-project basis (rather than based on the setup of the build environment)?

No, I'm talking about the GOPROXY environment variable.

https://groups.google.com/forum/#!topic/golang-dev/FTMScX1fsYk

1. Vendor at top level of module will keep working (this is a change from original docs).
2. We'll make proxies very very easy to set up, including as file:/// URLs pointing at a shared file server you have in your company, or as https:/// URLs to static file servers.