cmd/go: we're fetching github.com?go-get=1

[bradfitz]

I just noticed with "go install -v" that we're fetching https://github.com?go-get=1, which seems wrong:

dev:barlogaamp $ GO111MODULE=on go install -v
Fetching https://golang.org/x/crypto/ssh?go-get=1
go: finding github.com/bradfitz/private/sonos latest
Parsing meta tags from https://golang.org/x/crypto/ssh?go-get=1 (status code 200)
get "golang.org/x/crypto/ssh": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at https://golang.org/x/crypto/ssh?go-get=1
get "golang.org/x/crypto/ssh": verifying non-authoritative meta tag
Fetching https://golang.org/x/crypto?go-get=1
Parsing meta tags from https://golang.org/x/crypto?go-get=1 (status code 200)
go: finding github.com/bradfitz/private latest
Fetching https://github.com?go-get=1
Parsing meta tags from https://github.com?go-get=1 (status code 200)
go: finding golang.org/x/crypto/ssh latest
Fetching https://golang.org/x/crypto?go-get=1
Parsing meta tags from https://golang.org/x/crypto?go-get=1 (status code 200)
get "golang.org/x/crypto": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at https://golang.org/x/crypto?go-get=1
go: finding golang.org/x/crypto latest
go: import "github.com/bradfitz/private/barlogaamp" ->
        import "github.com/bradfitz/private/sonos": cannot find module providing package github.com/bradfitz/private/sonos

My program's imports are:

package main

import (
        "context"
        "log"
        "time"

        "golang.org/x/crypto/ssh"
        "github.com/bradfitz/private/sonos"
)

Where github.com/bradfitz/private is a private github repo.

In my ~/.gitconfig I have:

[url "ssh://[email protected]/"]
     insteadOf = https://github.com/

Seems like this only affects modules mode.

[bcmills]

That probably comes from this loop:

go/src/cmd/go/internal/modload/import.go

Lines 153 to 183 in f2131f6

	for p := path; p != "."; p = pathpkg.Dir(p) {
	// We can't upgrade the main module.
	// Note that this loop does consider upgrading other modules on the build list.
	// If that's too aggressive we can skip all paths already on the build list,
	// not just Target.Path, but for now let's try being aggressive.
	if p == Target.Path {
	// Can't move to a new version of main module.
	continue
	}
	info, err := Query(p, "latest", Allowed)
	if err != nil {
	continue
	}
	m := module.Version{Path: p, Version: info.Version}
	root, isLocal, err := fetch(m)
	if err != nil {
	continue
	}
	_, ok := dirInModule(path, m.Path, root, isLocal)
	if ok {
	return module.Version{}, "", &ImportMissingError{ImportPath: path, Module: m}
	}
	// Special case matching the one above:
	// if m.Path matches path, assume adding it to the build list
	// will either add the right code or the right code doesn't exist.
	if m.Path == path {
	return module.Version{}, "", &ImportMissingError{ImportPath: path, Module: m}
	}
	}

(I'm attempting to factor it out in https://golang.org/cl/128136, but that probably doesn't change the symptom.)

Perhaps we should hard-code some well-known constraints on module paths: for example, paths beginning with github.com must have at least two subsequent path components. That would at least save some lookup latency for modules that can't be fetched (#26874).

Are you able to fetch the private repos otherwise? (That's #26134 in general, I think.)

[bradfitz]

Are you able to fetch the private repos otherwise? (That's #26134 in general, I think.)

No. I'll leave a comment there.

[gopherbot]

Change https://golang.org/cl/129683 mentions this issue: cmd/go: treat VCS errors as hard errors in module search