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

Jump to bottom

cmd/go: go env GOWORK does not reflect -workfile #51171

Closed
hyangah opened this issue Feb 13, 2022 · 9 comments
Closed

cmd/go: go env GOWORK does not reflect -workfile #51171

hyangah opened this issue Feb 13, 2022 · 9 comments
Labels
FrozenDueToAge GoCommand cmd/go NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone
Go1.18

Comments

@hyangah
Copy link
Contributor

hyangah commented Feb 13, 2022

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

$ go version
go version go1.18beta2 darwin/amd64

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

$ go env -w GOFLAGS=-workfile=off

$ go env GOFLAGS GOWORK
-workfile=off
/Users/hakim/projects/editor/go.work

What did you do?

Set -workfile=off to disable go.work temporarily using go env -w.
I verified go work commands work as expected (iow ignoring the go.work file).
But, go env GOWORK still prints the ignored go.work file.

With this broken, there is no feedback that indicates whether go.work is affecting my build or not.

What did you expect to see?

go env GOWORK outputs the value reflecting the current -workfile value.

What did you see instead?

Unchanged behavior.

Similarly -

% go env -w GOFLAGS=-workfile=/Users/hakim/projects/editor/something.work
% go env GOWORK                                                          
/Users/hakim/projects/editor/go.work
% go list
reading go.work: open /Users/hakim/projects/editor/something.work: no such file or directory

cc @matloob
@gopherbot
Copy link

Change https://go.dev/cl/385659 mentions this issue: cmd/go: make sure GOWORK reflects the -workfile flag

@dmitshur
Copy link
Contributor

@matloob Do you think this needs to be fixed in 1.18 release? If so, please add release-blocker label, otherwise please move it to another milestone. (Edit: The CL that just came in suggests the former, so I'll apply the release-blocker label—please correct if needed.)

Also CC @bcmills as cmd/go owner.

@dmitshur dmitshur added GoCommand cmd/go NeedsFix The path to resolution is known, but the work has not been done. labels Feb 14, 2022
@dmitshur dmitshur added this to the Go1.18 milestone Feb 14, 2022
@matloob
Copy link
Contributor

matloob commented Feb 15, 2022

We've realized that -workfile was a mistake. We're going to use GOWORK to set the go.work file path so that there's no more discrepancy between GOWORK and the former -workfile flag.

go env GOWORK will still report the actual workfile found if it was set to the empty string or auto.

I'm working on a CL to fix this.

@gopherbot
Copy link

Change https://go.dev/cl/385995 mentions this issue: cmd/go: set go.work path using GOWORK, and remove -workfile flag

@findleyr findleyr mentioned this issue Feb 15, 2022
Closed
@mvdan
Copy link
Member

mvdan commented Feb 15, 2022

I'm a bit confused by this decision; was -modfile also a mistake, and should we point users towards GOMOD=foo.mod go build rather than go build -modfile=foo.mod as well? Or is the go.work case very different from go.mod?

@bcmills
Copy link
Contributor

bcmills commented Feb 15, 2022 •
edited by dmitshur

-modfile is a bit weird because go env GOMOD points to the actual module root even if the -modfile flag redirects edits to a different file. (That is; you can't use -modfile to enter or leave a module.)

In contrast, setting GOWORK (or, formerly, -workfile) does allow you to enter or leave a workspace, independent of your working directory.

@mvdan
Copy link
Member

mvdan commented Feb 15, 2022

even if the -modfile flag redirects edits to a different file.

Hmm. As far as I know it redirects reads as well as writes, no? But point taken that it can't be used to enter or leave a module.

If the -modfile and -workfile behave differently, then avoiding very similar flags sounds like a good idea to avoid confusion.

To close the loop in terms of avoiding misuse, I hope we would error out if a user attempts to do GOMOD=foo.mod go list rather than go list -modfile=foo.mod. That doesn't seem to be the case right now; I can set GOMOD, and it gets silently ignored by cmd/go.

@bcmills
Copy link
Contributor

bcmills commented Feb 15, 2022

I hope we would error out if a user attempts to do GOMOD=foo.mod go list rather than go list -modfile=foo.mod. That doesn't seem to be the case right now

I think that would be reasonable. (For Go 1.19! 😉)

@mvdan mvdan mentioned this issue Feb 15, 2022
Open
@mvdan
Copy link
Member

mvdan commented Feb 15, 2022

Filed #51217 as a reminder, thanks!

@golang golang locked and limited conversation to collaborators Feb 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
6 participants
@dmitshur @mvdan @hyangah @bcmills @gopherbot @matloob