proposal: cmd/go: GOWORK env var should be off by default

[bep]

This is certainly a duplicate of the rejected #51967 – but some months have passed and people have been using go.work in real life projects.

One of the great thing about Go's build tools is that you in most cases can do a go install in a random Go project and get a fully working executable.

With GOWORK=on as a default, that is no longer the case:

• If you have a go.work file committed to CVS, then that file will be used for module resolution.
• If you have that file in .gitignore then you will get a different build compared to some other person who clones and builds your project.

I see arguments in #51967 that you should really control this with Make scripts and similar, which is an argument I find odd. The production build is where the defaults should be directed and, again, one beauty of Go's build tools is the simplicity of just doing go install.

A related issue #53502 is discussing whether go.work should be committed to CVS or not, a question that might have been possible to answer if GOWORK=off was the default.

The final argument in the #51967 thread was:

Given that there are no new footguns here, just the same ones we had in replace directives ...

The big difference here is that the foot gun now is invisible.

With replace directives we had a well defined situation of "development replace directives should be temporary and never be committed to CVS". It took some care to live by that, and I have certainly shot myself in the foot more than once, but the current situation is that I have to either 1) Not use go.work files or 2) Create Make files for all of my projects (or some other tool to set GOWORK=off), which I would need to remember to use myself and document so others also remembers not to just do the simple go install.

The ideal situation would be to be able to turn on GOWORK when I'm doing development, e.g. GOWORK=on code .

[bcmills]

One of the great thing about Go's build tools is that you in most cases can do a go install in a random Go project and get a fully working executable.

If you go install a specific version of a tool (such as go install golang.org/x/tools/gopls@latest), that should already be completely independent of any workspace. I think we do still need to work on getting more projects to adopt that form in their install instructions, but even without workspace mode it is already far preferable to go install without an explicit version (which — again, implicitly — uses the dependencies of the current module).

[bep]

If you go install a specific version of a tool (such as go install golang.org/x/tools/gopls@latest), t

So what you're saying that:

go install golang.org/x/tools/gopls@latest

May be different than:

git clone golang.org/x/tools/gopls
cd gopls
git checkout <latest-tag>
go install

???

[mvdan]

Those two commands have always been different - try it on a Go module using replace directives, for example.

[bep]

I have tried to use go.work files actively in multi module projects for the last few weeks, and I have had several debug sessions not understanding the behaviour, only remembering that I had a go.work file active. So my current take is that I cannot use go.work until the tools I use adapts to this (e.g. VS Code). And I have a hard time understand how that tooling would adapt to this, since the default behaviour I want would be GOWORK=off.