x/vgo: canonical import path checking breaks some existing packages

[rogpeppe]

go version devel +104445e Wed Feb 7 19:22:09 2018 +0000 linux/amd64 vgo:2018-02-20.1

I'm creating this issue to record the issue. It may be that nothing should be done but get the repo to fix their import paths.

See https://github.com/Altoros/gosigma/issues/2

This issue causes vgo to fail with this error:

vgo: github.com/altoros/gosigma: module path of repo is github.com/Altoros/gosigma, not github.com/altoros/gosigma (wrong case)

It imports OK when using the normal go tool.

[yansal]

Dup of #23974 I believe.

[kardianos]

I agree this is a duplicate. Closing in favor of linked issue in previous comment.

[rogpeppe]

FWIW I don't think this is exactly the same issue, as the repository in question here has neither been redirected or renamed.

[utrack]

I'd suggest reopening this issue @kardianos - it's not about renames.
If a package path (username?) has uppercase letters in his nickname then vgo breaks the build, ex.:

vgo: resolving import "github.com/Sirupsen/logrus"
vgo: import "github.com/utrack/dplay-go" ->
        import "github.com/Sirupsen/logrus": module path of repo is github.com/sirupsen/logrus, not github.com/Sirupsen/logrus (wrong case)

[rsc]

Probably this check is too picky, but I'm not 100% sure what to replace it with.

FWIW, it's not the case that vgo just rejects upper-case letters (it's rejecting lower case for altoros). It rejects import paths that don't match the spelling used on GitHub, specifically to avoid thinking that github.com/Altoros/gosigma and github.com/altoros/gosigma are different import paths. Note that the github account is Altoros not altoros.

[IngCr3at1on]

just out of curiosity @rsc do you mind if I ask why it can't be made to fetch the repo into the expected path (it resolved, seems like an error should only occur if resolution fails entirely); I'm sure I'm missing something obvious I'd just like to know what it is? 😄

[bleggett]

Since AFAIK the case mismatch doesn't seem to prevent stock go from compiling and running the code, I'd suggest that this should be true of vgo as well, unless there's a technical obstacle to that. If vgo is smart enough to correctly identify the problem, it should be smart enough to warn the user and move on.

Making this a vgo build warning would be the ideal outcome, if that warning could be output on every invocation of build, or at least on initial fetch, but that is probably easier said than done.

[gopherbot]

Change https://golang.org/cl/107657 mentions this issue: cmd/go/internal/modfetch: update for new gitrepo backend