It's just a binary file. Why insist in invoking a special command when you can just rm it?

@gophun For the same reason go clean -i even exists in the first place.

The fact that it doesn't work seemed like a bug to me.

In a practical sense:

1. Because the install location of the binary is dependent on numerous environmental factors and it's install location (which isn't reported at install time) is otherwise not known to the user. So manually performing the deletion could be non-obvious to a user.
2. For completeness. Allowing the install, but not the deletion, is asymmetric.
3. Having the same environment that determines that location to install and remove allows for easier scripting and automation via the same defined environmental controls.
4. Again, because the command already exists, and just doesn't seem to be working for this case.

The docs for go install say:

Executables (main packages) are installed to the directory named by the GOBIN environment variable, which defaults to $GOPATH/bin or $HOME/go/bin if the GOPATH environment variable is not set.

And the docs for go clean say:

Clean removes object files from package source directories. The go command builds most objects in a temporary directory, so go clean is mainly concerned with object files left by other tools or by manual invocations of go build.

If a package argument is given or the -i or -r flag is set, clean removes the following files from each of the source directories corresponding to the import paths:

_obj/ old object directory, left from Makefiles
_test/ old test directory, left from Makefiles
_testmain.go old gotest file, left from Makefiles
test.out old test log, left from Makefiles
build.out old test log, left from Makefiles
*.[568ao] object files, left from Makefiles

DIR(.exe) from go build
DIR.test(.exe) from go test -c
MAINFILE(.exe) from go build MAINFILE.go
*.so from SWIG

So it would seem that go clean is functioning properly, since the executable is not in the source directory.

Also, I don't think something like go clean github.com/Rican7/define@latest should work, given that go install doesn't seem to record the version it installed anywhere, and I think it would be confusing if go clean github.com/Rican7/define@v1.0.0 were to delete what go install github.com/Rican7/define@v1.0.1 installs.

I can see the argument for go clean github.com/Rican7/define working, but then the lack of symmetry could be confusing.

@bcmills @matloob per owners.

I think this might be a documentation issue. The words (what 'go install' would create) applied to what go install created before the new go install module@version functionality was added. We should maybe remove that phrase.

I guess it would not hurt if go install reported the path in which the binary was installed. Users new to Go often don’t know about GOPATH/bin.

I guess it would not hurt if go install reported the path in which the binary was installed.

That could be helpful, yea.

Users new to Go often don’t know about GOPATH/bin.

Especially since setting GOPATH is no longer required with module mode.

I guess it would not hurt if go install reported the path in which the binary was installed.

One easy but slightly hacky way to do this: install it, then immediately run install -n:

$ go install golang.org/x/debug/cmd/viewcore@latest
$ go install -n golang.org/x/debug/cmd/viewcore@latest
touch /Users/thanm/go1/bin/viewcore
$ 

I don't think something like go clean github.com/Rican7/define@latest should work, given that go install doesn't seem to record the version it installed anywhere, and I think it would be confusing if go clean github.com/Rican7/define@v1.0.0 were to delete what go install github.com/Rican7/define@v1.0.1 installs.

The installed version should be recorded in a metadata block in the binary (compare go version -m). So I think it would actually be feasible to make go clean -i github.com/Rican7/define@v1.0.1 only clean v1.0.1 — but I also think that would be a confusing UX.

That said, I do think it would be reasonable for go clean -i github.com/Rican7/define@v1.0.1 to unconditionally remove the binary at the location that would be installed by go install github.com/Rican7/define@v1.0.1, even if the version doesn't match. That's not fundamentally different from what should happen if, say, you were to run go install github.com/Rican7/define@v1.0.1 before that call to go clean -i.

I guess it would not hurt if go install reported the path in which the binary was installed. Users new to Go often don’t know about GOPATH/bin.

See:

• cmd/go: command to print out the directory Go will install binaries into #45546
• cmd/go: default GOBIN to GOPATH[0]/bin when outside of GOPATH? #23439