About the change for default "-mod=vendor" in Go 1.14

2,986 views
Skip to first unread message

T L

unread,
Jan 8, 2020, 8:13:34 AM1/8/20
to golang-nuts
 The release notes (https://tip.golang.org/doc/go1.14) says

When the main module contains a top-level vendor directory and its go.mod file specifies go 1.14 or higher, the go command now defaults to -mod=vendor for operations that accept that flag. A new value for that flag, -mod=mod, causes the go command to instead load modules from the module cache (as when no vendor directory is present).


When -mod=vendor is set (explicitly or by default), the go command now verifies that the main module's vendor/modules.txt file is consistent with its go.mod file.


I checked it with Go SDK 1.14 beta 1, and it seems the go command doesn't behave as the above described.
After I run "go mod vendor", all the dependencies are placed under the vendor folder with a modules.txt file.
Then I remove all cached modules from GOPATH and disconnect the network, and run "go build" again,
the command still tries to connect network to download the dependency modules and it fails for sure.
But "go build -mod=vendor" runs okay. Isn't "go build" equivalent to "go build -mod=vendor" since Go SDK 1.14?


Beside this, would this break the semantic of the vendor folder?
Now, for many of my projects, I use the vendor folder as a package-search-priority folder.
I have modified some packages in the vendor, and many of the packages have disappeared from the internet.
Is there a way to let these projects continue compiling okay with Go SDK 1.14+?

Sean Liao

unread,
Jan 8, 2020, 11:51:59 AM1/8/20
to golang-nuts
works for me when tested with gp1.14beta1, are you sure your go.mod has the  "go 1.14" directive?
go's tooling currently assumes vendor is a full local copy of all code needed to build a module
with modules the recommended way is to have your patched  / unavailable module somewhere else
and point to it with either standard require or a replace

T L

unread,
Jan 9, 2020, 3:38:56 AM1/9/20
to golang-nuts
Yes, when I change the "go 1.13" directive to "go 1.14", it suggests I need to run 'go mod vendor' to sync.
After the sync, it works. Thanks for the help.

So if the directive is 1.13, no default "-mod=vendor" compiler flag is set? And not any message is suggested?
This should work, but it is to tedious, for there are tons of old dependency packages.
I need to create tons of go.mod files under those package folders and add tons of replace lines in the main go.mod file.

If Go SDK 1.14+ also support a special folder vendor_legacy, then things would become simpler.

Amnon Baron Cohen

unread,
Jan 9, 2020, 5:42:52 AM1/9/20
to golang-nuts
Things would be much, much, simpler if we kill off the vendor folder.

It always was a horrible hack.

T L

unread,
Jan 9, 2020, 8:51:27 AM1/9/20
to golang-nuts
I rearranged the folder structures of my projects. It looks things are not that bad.
The last versions of most of the dependencies still keep API capabilities.
There are only about 5 packages need the replace line hack.

 
Reply all
Reply to author
Forward
0 new messages