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: "go get -u" should handle missing hash #32005

Closed
shuLhan opened this issue May 13, 2019 · 6 comments
Closed

cmd/go: "go get -u" should handle missing hash #32005

shuLhan opened this issue May 13, 2019 · 6 comments

Comments

@shuLhan
Copy link
Contributor

@shuLhan shuLhan commented May 13, 2019

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

$ go version
go version devel +6dc88be30d Mon May 13 17:25:28 2019 +0700 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/ms/go/bin"
GOCACHE="/home/ms/.cache/go-build"
GOENV="/home/ms/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ms/go"
GOPROXY="https://proxy.golang.org"
GOROOT="/home/ms/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/ms/share/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build143933761=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Create a module with the following go.mod file,

module github.com/shuLhan/sandbox/issuenew

go 1.13

require golang.org/x/xerrors v0.0.0-20190513163551-000000000001

The VCS hash for package xerrors is deliberately modified to point to commit hash that does not exist (000000000001).

On the package module root directory, run go get -u golang.org/x/xerrors.

What did you expect to see?

The "go get -u" command should update the package to latest commit on repository even if hash is not found as long as package use "latest" (incompatible?) mode.

In a perfect world, we will never seen a commit missing from master branch. However, sometimes rebase and force push happened, for any reason.

Rationale: when user use "latest" mode, we assume that they know what they are doing and the know what would happened.

What did you see instead?

The "go get -u" command return 410 Gone.

go: finding golang.org/x/xerrors v0.0.0-20190513163551-000000000001
go: golang.org/x/xerrors@v0.0.0-20190513163551-000000000001: reading https://proxy.golang.org/golang.org/x/xerrors/@v/v0.0.0-20190513163551-000000000001.info: 410 Gone

Currently, the only way to fix this is by re-initializing module back (removing "require" statements and removing go.sum file).

@andybons andybons changed the title module: "go get -u" should handle missing hash cmd/go: "go get -u" should handle missing hash May 13, 2019
@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented May 13, 2019

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented May 13, 2019

This is somewhat related to #30831 and #26902, in that we're emitting an error before the upgrade due to a failure that wouldn't be present after upgrading anyway.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented May 21, 2019

we're emitting an error before the upgrade due to a failure that wouldn't be present after upgrading anyway.

We don't know that. go get -u might choose a "latest" that is before that pseudo-version, or maybe that module contains within it other requirements that are newer than "latest" for their own modules. In general ignoring unreachable modules is not safe.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented May 21, 2019

@rsc, since the existing entry in the go.mod file is a well-formed semantic version, we can compare it with latest and only report an error if it is semantically lower.

That said, if we can't fetch the listed commit, then we also don't know what packages it imports or what other module versions it requires. If we don't have that information, then we could indeed end up downgrading one or more transitive dependencies.

For rebases and force-pushes in particular, in many cases you will be able fetch the missing version from a proxy or mirror, and for the remainder you can always hand-edit (or go mod edit) the go.mod file.

@bcmills bcmills closed this May 21, 2019
@thepudds

This comment has been minimized.

Copy link

@thepudds thepudds commented May 21, 2019

@bcmills was this intentionally closed? Just checking.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented May 22, 2019

Yes, this was closed intentionally: if we can't load the module graph, we can't (in general) decide which modules to upgrade.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.