Skip to content

cmd/go: list reports packages as stale immediately after their "go get" #23797

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

Closed
siebenmann opened this issue Feb 12, 2018 · 7 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@siebenmann
Copy link

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

go version devel +c52e27e68d Sun Feb 11 20:41:48 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

This doesn't happen on Go 1.9.4.

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

GOARCH="amd64"
GOOS="linux"

What did you do?

Here is a simple reproduction, showing a just fetched and built command package being reported as stale due to a stale dependency.

$ export GOPATH=/tmp/gp
$ mkdir $GOPATH
$ go get mvdan.cc/sh/cmd/shfmt
$ go list -f '{{.ImportPath}} - {{.Stale}} - {{.StaleReason}}' mvdan.cc/sh/cmd/shfmt
mvdan.cc/sh/cmd/shfmt - true - stale dependency: mvdan.cc/sh/fileutil

This appears to happen for anything that has dependencies outside of the core packages, including dependencies to golang.org/x packages.

@mvdan mvdan changed the title go list reports things as stale when they shouldn't be cmd/go: list reports packages as stale immediately after their "go get" Feb 13, 2018
@mvdan mvdan added this to the Go1.11 milestone Feb 13, 2018
@mvdan mvdan added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 13, 2018
@mvdan
Copy link
Member

mvdan commented Feb 13, 2018

Seems related to whether or not go install was called on the dependencies directly:

$ go install -v mvdan.cc/sh/cmd/shfmt
$ go list -f '{{.ImportPath}} - {{.Stale}} - {{.StaleReason}}' mvdan.cc/sh/cmd/shfmt
mvdan.cc/sh/cmd/shfmt - true - stale dependency: mvdan.cc/sh/fileutil
$ go install -v mvdan.cc/sh/fileutil
$ go list -f '{{.ImportPath}} - {{.Stale}} - {{.StaleReason}}' mvdan.cc/sh/cmd/shfmt
mvdan.cc/sh/cmd/shfmt - false -

@mvdan
Copy link
Member

mvdan commented Feb 13, 2018

go build -v mvdan.cc/sh/fileutil does not seem to fix it, though.

@mvdan
Copy link
Member

mvdan commented Feb 13, 2018

Seems like the .a file for the library isn't being written to by go install when called on the package that imports the library. But, if go install is called directly on the library, it does write the .a file.

useCache on the library package also returns different results on both of these cases - it's returns true only when go install was called on the library directly.

I've tried debugging this further and possible fixes, but I'm not sure how this is supposed to behave. @rsc, thoughts?

@bradfitz bradfitz modified the milestones: Go1.11, Go1.10 Feb 13, 2018
@bradfitz
Copy link
Contributor

I'll actually promote this to Go 1.10 because it involves the new build cache (potentially). I'll let Russ decide whether it's important for 1.10.

@bradfitz
Copy link
Contributor

We decided in the release meeting to think about this for Go 1.10.1.

@andybons
Copy link
Member

Bumping to 1.10.2 as there doesn't appear to be a fix yet.

@rsc
Copy link
Contributor

rsc commented Apr 18, 2018

Duplicate of #23818, #24558.

@rsc rsc closed this as completed Apr 18, 2018
@FiloSottile FiloSottile modified the milestones: Go1.10.2, Go1.11 Apr 24, 2018
@golang golang locked and limited conversation to collaborators Apr 24, 2019
@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants