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

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

Open
bep opened this issue Aug 21, 2022 · 4 comments
Open

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

bep opened this issue Aug 21, 2022 · 4 comments
Labels
Milestone

Comments

@bep
Copy link
Contributor

bep commented Aug 21, 2022

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 .

@bep bep added the Proposal label Aug 21, 2022
@gopherbot gopherbot added this to the Proposal milestone Aug 21, 2022
@bcmills
Copy link
Member

bcmills commented Aug 23, 2022

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
Copy link
Contributor Author

bep commented Sep 2, 2022

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
Copy link
Member

mvdan commented Sep 2, 2022

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

@bep
Copy link
Contributor Author

bep commented Sep 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

4 participants