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

[hyangah]

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]

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

[dmitshur]

@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.

[matloob]

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]

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

[mvdan]

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]

-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]

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]

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]

Filed #51217 as a reminder, thanks!