Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: mod vendor should work offline #28029

mihaiav opened this issue Oct 4, 2018 · 4 comments


None yet
4 participants
Copy link

commented Oct 4, 2018

What version of Go are you using (go version)?

go1.11 darwin/amd64

What operating system and processor architecture are you using (go env)?

OSX 10.14

What did you do?

go mod vendor -v

What did you expect to see?

It tries to download the dependencies from the network. Unfortunately some dependencies are not available over the network because I'm using vanity domain names and the infrastructure that provides support for the vanity domain name(i.e. the http server serving the go vanity meta tags) depends on the program I'm trying to build/vendor.

I need a way to copy the dependencies into the vendor directory from the local disk/GOPATH instead to download them just like govendor +external tool did. Is there any such feature planned?

I've tried to set GOPROXY to GOPATH ( export set GOPROXY=$GOPATH/src ) but when I do that go mod vendor reports no dependencies to vendor

@mvdan mvdan changed the title go mod vendor should work offline cmd/go: mod vendor should work offline Oct 5, 2018


This comment has been minimized.

Copy link

commented Oct 5, 2018

/cc @bcmills


This comment has been minimized.

Copy link

commented Oct 6, 2018

Hi @mihaiav, is your example a case where go get in 1.11 seems to work for you to get X, but go mod vendor fails for X? Or does go get in 1.11 seem to exhibit the same issue you are reporting for go mod vendor?

I suspect you have a few options, but probably worthwhile to say a few more words about your goals.

Vendoring with modules in 1.11 might be one approach that ends up working out for you, and that might be the simplest answer.

That said, an alternative approach might be one of a few different options involving GOPROXY environment variable.

For example, GOPROXY=file:///filesystem/path environment variable tells the go commands to use a filesystem (local or remote) to resolve dependencies, without any need to have an actual running proxy process. In general for modules, the go command (e.g., go get or go build) automatically stores downloaded dependencies in its local cache ($GOPATH/pkg/mod), and its cache layout is the same as the requirements for a proxy, so that cache can be used as the content for a filesystem-based GOPROXY or simple webserver used as a GOPROXY. In addition, go mod download populates $GOPATH/pkg/mod/cache/download, which means that command can be used to pre-populate or update the contents for a GOPROXY. You can read some more details in the tip documentation, especially the description at the end of that 'Module proxy protocol' documentation section.

Also, here is a nice end-to-end example from @myitcv of using GOPROXY with a filesystem:

However, the best approach likely depends on exactly what you are trying to do, and what your exact constraints are.


This comment has been minimized.

Copy link

commented Nov 16, 2018

go mod vendor does work offline if all of the modules are already in the local module cache (e.g., after a successful go mod download).

Bootstrapping an unpublished module into the module cache is a separate problem, for which I've filed #28835. I'd rather do that than copy the source directly into the vendor directory, since there is some metadata there (in vendor/modules.txt) that expects vendor contents to match the actual modules. (See also #27348.)

@bcmills bcmills added this to the Go1.13 milestone Nov 16, 2018


This comment has been minimized.

Copy link

commented Nov 16, 2018

You should be able to set up a replace directive pointing to the local filesystem, then run go mod vendor to copy the replaced source into the vendor directory.

The mod_vendor_replace test verifies that behavior. It's part of the fix for #27859, so you may have to build from source (from commit f8153fc or later) to pick up that fix.

@bcmills bcmills closed this Nov 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.