x/tools/cmd/goimports: unnecessary rename of imports

[rsc]

In GOPATH mode:

$ go get gopkg.in/russross/blackfriday.v2
$ echo 'package p; import "gopkg.in/russross/blackfriday.v2"; var _ blackfriday.Node' | goimports
package p

import blackfriday "gopkg.in/russross/blackfriday.v2"

var _ blackfriday.Node
$ 

Why did goimports rename this import? It should not be doing that. The package clause in the package already says blackfriday, and furthermore the package name follows the standard import path rules for package names on gopkg.in.

/cc @heschik @bradfitz

[bradfitz]

This was was intentional. See #28428 and https://go-review.googlesource.com/c/152000

Closing, but feel free to reopen one of these bugs if you strongly disagree.

[heschi]

Yeah. goimports only understands SIV-style /vN suffixes and adds names to everything it finds surprising. It could be taught the gopkg.in convention, I suppose, but I'd like to have a coherent policy about what it should and shouldn't understand, per the discussion in #28428 (comment).

[heschi]

Hm. I'd forgotten that gopkg.in is already specially handled by the go command.

As a special case, module paths beginning with gopkg.in/ continue to use the
conventions established on that system: the major version is always present,
and it is preceded by a dot instead of a slash: gopkg.in/yaml.v1
and gopkg.in/yaml.v2, not gopkg.in/yaml and gopkg.in/yaml/v2.

That's some justification to support it in goimports, I suppose.

[rsc]

As @heschik pointed out, gopkg.in is a known special case in the go command, so I agree that it should be a known special case here. It doesn't make sense to penalize gopkg.in users by renaming all their imports unnecessarily.

[gopherbot]

Change https://golang.org/cl/157357 mentions this issue: imports: drop anyting after . in package names