x/tools/gopls: update unstable version installation instruction

[hyangah]

Neither works quietly. In favor of the experimental workspace module option, can we remove the use of replace?

~$ gotip get golang.org/x/tools/gopls@master golang.org/x/tools@master
go: downloading golang.org/x/tools/gopls v0.0.0-20210622191215-6d3e43932267
go: downloading golang.org/x/tools v0.1.4-0.20210622191215-6d3e43932267
go get: installing executables with 'go get' in module mode is deprecated.
	Use 'go install pkg@version' instead.
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.

~$ gotip install golang.org/x/tools/gopls@master golang.org/x/tools@master
go install: golang.org/x/tools/gopls@master (in golang.org/x/tools/gopls@v0.0.0-20210622191215-6d3e43932267):
	The go.mod file for the module providing named packages contains one or
	more replace directives. It must not contain directives that would cause
	it to be interpreted differently than if it were the main module.

[ianthehat]

I vote we remove the replace and all attempt to use the new experimental go.work file instead to see if it solves the workflow well for us.

[pwaller]

Following the instructions on working with generic code, I hit this error message during install. Not clear what the right course of action is, would appreciate advice. (It also seems worthwhile to update that instruction!)

[hyangah]

@pwaller please follow the instruction @jayconrod described in #43684 (comment)

# Create an empty go.mod file, only for tracking requirements.
cd $(mktemp -d)
go mod init empty-module-for-installing-a-tool

# Use 'go get' to add requirements and to ensure they work together.
go get golang.org/x/tools/gopls@master golang.org/x/tools@master

# Install using the selected versions in go.mod.
go install golang.org/x/tools/gopls

Actually, the above instruction should be the new instruction for unstable version installation until we migrate to a separate repository with one module. (cc @stamblerre @ianthehat @findleyr )

I considered removing replace directive, but even without replace, I doubt go install golang.org/x/tools@master golang.org/x/tools/gopls@master would behave as we hoped - go install doesn't support changing dependencies versions AFAIK. go install golang.org/x/tools/gopls@master may be building a version of gopls neither its developers nor the builders built/tested. go.work is designed for developers (who check out the source in the local directory), so I don't think that supports this use case.

Alternatives I considered were

1. keep the current replace directive and ask users to git clone; cd tools/gopls; go install ., or
2. check in go.work in x/tools and ask users to git clone; cd tools; go build -o gopls-unstable ./gopls. (note: go install won't work here).

But gopls built in these ways won't have complete version info (runtime/debug.BuildInfo) due to #29228 - which will be less ideal for gopls&vscode-go maintainers when triaging issues.

[gopherbot]

Change https://golang.org/cl/354169 mentions this issue: gopls/doc/advanced.md: update unstable version installation instruction

[hyangah]

The new instruction based on #46880 (comment) is complicated and not user friendly. We plan to look into a way to simplify it. Current ideas:

• Provide a script to do the work, or
• Let gopls handle installation of it. e.g. gopls get unstable or gopls install unstable which runs the sequence of go commands and the dummy main module creation.

[hyangah]

If #50603 is implemented, we can just utilize
git clone go.googlesource.com/tools -> checkout to the wanted commit -> go install from the gopls directory.

That will achieve:

• pick up the replace formula described as in the go.mod.
• produce a binary with the version info other than (dev).
• place the built binary to the default go install directory.
• the new instruction is more user-friendly: users know git clone and go install.

@golang/tools-team