为什么go get -u在模块目录中花费很长时间，而在golang中却很快完成？

Question

I have a very slow unstable network.

First Observation Running Locally

For example, When I run go get -u github.com/jinzhu/gorm in a fresh module directory (which has main.go). It prints out many lines and will never be able to complete successfully in my local environment due to a slow unstable network.

But if I run the same command outside the module directory, it can be completed in a reasonable time without any stdout.

Second Observation Running Remotely

I have a remote VPS server which is located in USA. I create the same module directory there and run the same command inside the module on remote: go get -u github.com/jinzhu/gorm, and the go.mod will have the following content:

require (
    cloud.google.com/go v0.39.0 // indirect
    github.com/denisenkom/go-mssqldb v0.0.0-20190515213511-eb9f6a1743f3 // indirect
    github.com/golang/mock v1.3.1 // indirect
    github.com/google/btree v1.0.0 // indirect
    github.com/google/pprof v0.0.0-20190515194954-54271f7e092f // indirect
    github.com/jinzhu/gorm v1.9.8 // indirect
    github.com/jinzhu/inflection v0.0.0-20190603042836-f5c5f50e6090 // indirect
    github.com/kr/pty v1.1.4 // indirect
    github.com/lib/pq v1.1.1 // indirect
    go.opencensus.io v0.22.0 // indirect
    golang.org/x/crypto v0.0.0-20190530122614-20be4c3c3ed5 // indirect
    golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522 // indirect
    golang.org/x/image v0.0.0-20190523035834-f03afa92d3ff // indirect
    golang.org/x/lint v0.0.0-20190409202823-959b441ac422 // indirect
    golang.org/x/mobile v0.0.0-20190509164839-32b2708ab171 // indirect
    golang.org/x/mod v0.1.0 // indirect
    golang.org/x/net v0.0.0-20190603091049-60506f45cf65 // indirect
    golang.org/x/oauth2 v0.0.0-20190523182746-aaccbc9213b0 // indirect
    golang.org/x/sys v0.0.0-20190602015325-4c4f7f33c9ed // indirect
    golang.org/x/time v0.0.0-20190308202827-9d24e82272b4 // indirect
    golang.org/x/tools v0.0.0-20190603152906-08e0b306e832 // indirect
    google.golang.org/appengine v1.6.0 // indirect
    google.golang.org/genproto v0.0.0-20190530194941-fb225487d101 // indirect
    google.golang.org/grpc v1.21.0 // indirect
    honnef.co/go/tools v0.0.0-20190602125119-5a4a2f4a438d // indirect
)

and then I run go mod tidy, the go.mod becomes:

require (
    cloud.google.com/go v0.39.0 // indirect
    github.com/denisenkom/go-mssqldb v0.0.0-20190515213511-eb9f6a1743f3 // indirect
    github.com/google/go-cmp v0.3.0 // indirect
    github.com/jinzhu/gorm v1.9.8
    github.com/jinzhu/inflection v0.0.0-20190603042836-f5c5f50e6090 // indirect
    github.com/lib/pq v1.1.1 // indirect
    golang.org/x/crypto v0.0.0-20190530122614-20be4c3c3ed5 // indirect
    google.golang.org/appengine v1.6.0 // indirect
)

But if I remove the require(...) section completely from go.mod and then execute go mod tidy, I get the following content in go.mod:

require github.com/jinzhu/gorm v1.9.8

Just one require. And with this one line, I run go build, the module can be built and ran successfully without any problems.

So I am very confused what go get -u really does in my module directory.

My two questions:

• Should I run go get -u inside module directory or can I simply run it outside module directory?

• Why go get -u outside the module directory can complete easily? Dose it do the same download/upgrade compared to running inside the module directory?

I am using the latest stable golang go1.12.5. Because go get -u calls git and git calls curl, but curl is very bad on unstable network (compared to wget). I am unable to complete go get -u inside the module directory. I will get many error: RPC failed; The remote end hung up unexpectedly; fatal: early EOF; fatal: index-pack failed;. I don't know if there is a workaround for this problem or not. But I can use go get -u outside the module directory though.

Thanks a lot.

(Btw, if go get can use wget, it will work in my local environment. I never have any problems with wget and wget will finally complete the download after waiting for a long time. But unfortunately, wget is not a preferred tool by the current dev world)

Answer 1

Should I run go get -u inside module directory or can I simply run it outside module directory?

If you're using modules, you need to run it inside your module directory if you want it to actually update your go.mod / go.sum files.

Why go get -u outside the module directory can complete easily? Dose it do the same download/upgrade compared to running inside the module directory?

They're pretty different in behavior. go help get, go help module-get and go help modules should explain some of the differences and in your case check the module doc:

A common mistake is thinking go get -u foo solely gets the latest version of foo. In actuality, the -u in go get -u foo or go get -u foo@latest means to also get the latest versions for all of the direct and indirect dependencies of foo.

The go.mod for gorm includes a lot of stuff (https://github.com/jinzhu/gorm/blob/master/go.mod) including drivers for every possible database it supports, which seems pretty intense. Since you're just doing a blanket -u and not specifying @v1.9.3 or whatever, it's trying to update all of Gorm's dependencies (and the dependencies' dependencies!) in module-aware mode.