cmd/go: flag modcacherw does not take effect in the target package #64282
Assignees
Labels
FixPending
Issues that have a fix which has not yet been reviewed or submitted.
GoCommand
cmd/go
modules
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
mknyszek
added
NeedsInvestigation
seankhliao
changed the title
|
@marjus45, I'm not able to reproduce the behavior you report: Did you run any other commands before or after the |
|
Huh. Apparently it has something to do with running as |
|
Bisecting now. |
|
bcmills
added
NeedsFix
gopherbot
removed
the
NeedsInvestigation
|
@gopherbot, please backport to Go 1.21. This was a regression in Go 1.21 and has no clear workaround. |
|
Backport issue(s) opened: #64497 (for 1.21). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
|
Change https://go.dev/cl/546635 mentions this issue: |
|
Change https://go.dev/cl/550055 mentions this issue: |
|
Change https://go.dev/cl/550237 mentions this issue: |
|
Change https://go.dev/cl/551215 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Dec 19, 2023
…n' and 'go install' flags" This caused other problems, and for the purposes of the Go 1.22 release, we can just roll back to the Go 1.21 behavior and then decide in January what the correct path forward is. Revert of CL 546635. Unfixes #64282. Fixes #64738. For #57001. This reverts commit e44b8b1. Change-Id: I78753c76dcd0bc6dbc90caa17f73248c42e5f64a Reviewed-on: https://go-review.googlesource.com/c/go/+/551215 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Than McIntosh <thanm@google.com>
|
Rolled back due to causing #64738. |
rsc
added
the
okay-after-rc1
gopherbot
removed
the
okay-after-rc1
|
Change https://go.dev/cl/555436 mentions this issue: |
bcmills
added
the
FixPending
|
This is merged to the main branch, but due to the timing needs to be backported to the release branch. |
|
Change https://go.dev/cl/559218 mentions this issue: |
|
Change https://go.dev/cl/559198 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jan 31, 2024
…erw flag when downloading a module to determine what toolchain it needs Fixes #64282. Change-Id: I3f211c599ee70cb58254d0bc07eeb3c135124e58 Reviewed-on: https://go-review.googlesource.com/c/go/+/555436 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> (cherry picked from commit cc38c68) Reviewed-on: https://go-review.googlesource.com/c/go/+/559218 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
https://go.dev/cl/559218 was merged, so I'm removing the release-blocker label |
gopherbot
pushed a commit
that referenced
this issue
Jan 31, 2024
…erw flag when downloading a module to determine what toolchain it needs Fixes #64497. Updates #64282. Change-Id: I3f211c599ee70cb58254d0bc07eeb3c135124e58 Reviewed-on: https://go-review.googlesource.com/c/go/+/555436 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> (cherry picked from commit cc38c68) Reviewed-on: https://go-review.googlesource.com/c/go/+/559198 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
ezz-no
pushed a commit
to ezz-no/go-ezzno
that referenced
this issue
Feb 18, 2024
…go install' flags When the argument to 'go install' or 'go run' looks like a versioned package, we make a best effort to switch to a toolchain compatible with the module containing that package, by fetching its go.mod file and checking the go version it specifies. At this point in the code, we have not yet parsed the arguments given on the command line: instead, we just make a best effort to find one we can use to select a toolchain version. Since that toolchain may be newer, the command to install it may also include flags that are only supported by that Go version — and we don't want to fail due to an error that would be resolved by switching to a more appropriate toolchain. So at this point in the code we can't parse the flags in a way that will surface errors, but we want to make a best effort to parse the ones that we know about. It turns out that “parse the flags we know about” is already a familiar problem: that's also what we do in 'go test', so we can reuse the cmdflag library from that to do the best-effort pass of parsing. If it turns out that we don't need to switch toolchains after all, cmd/go's main function will parse the flags again, and will report any errors at that point. This fixes a regression, introduced in CL 497879, which caused 'go install -modcacherw pkg@version' to unset the write bit for directories created while selecting the toolchain to use. Fixes golang#64282. Updates golang#57001. Change-Id: Icc409c57858aa15c7d58a97a61964b4bc2560547 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/546635 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
ezz-no
pushed a commit
to ezz-no/go-ezzno
that referenced
this issue
Feb 18, 2024
…n' and 'go install' flags" This caused other problems, and for the purposes of the Go 1.22 release, we can just roll back to the Go 1.21 behavior and then decide in January what the correct path forward is. Revert of CL 546635. Unfixes golang#64282. Fixes golang#64738. For golang#57001. This reverts commit e44b8b1. Change-Id: I78753c76dcd0bc6dbc90caa17f73248c42e5f64a Reviewed-on: https://go-review.googlesource.com/c/go/+/551215 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Than McIntosh <thanm@google.com>
ezz-no
pushed a commit
to ezz-no/go-ezzno
that referenced
this issue
Feb 18, 2024
…g a module to determine what toolchain it needs Fixes golang#64282. Change-Id: I3f211c599ee70cb58254d0bc07eeb3c135124e58 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/555436 Auto-Submit: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Russ Cox <rsc@golang.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?I tested this on a clean Debian container.
go envOutputWhat did you do?
modcacherwflag withgo install:go-containerregistry@v0.16.1has read only permissions while their dependencies (go-cmp) has read-write permissions, as expected.What did you expect to see?
I expected to see the directory
go-containerregistry@v0.16.1to have read-write permissions, since I have set the flagmodcacherw.What did you see instead?
Instead
go-containerregistry@v0.16.1has read only permissions.I thinks this is a regression, since up to
v1.20I confirmed that it worked as expected.The text was updated successfully, but these errors were encountered: