Unable to deduce subpackages of private repository.

[slnt]

What version of Go and depare you using?

go version go1.8.3 darwin/amd64

dep rev c26c5b9264e8b978127e71d0411498233126be26

(This issue doesn't seem to happen with v0.3.0, however I experienced a similar issue when doing a dep ensure -add <package>)

What dep command did you run?

→ dep ensure -v
The following errors occurred while deducing packages:
  * "foo.internal.com/private-repo/subfolder/packageX": unable to deduce repository and source type for "foo.internal.com/private-repo/subfolder/packageX": unable to read metadata: go-import metadata not found
  * "foo.internal.com/private-repo/subfolder/packageY": unable to deduce repository and source type for "foo.internal.com/private-repo/subfolder/packageY": unable to read metadata: go-import metadata not found
  * "bar.internal/private/name/golang/name": unable to deduce repository and source type for "bar.internal/private/name/golang/name": unable to read metadata: unable to fetch raw metadata: failed HTTP request to URL "http://bar.internal/private/name/golang/name?go-get=1": Get http://bar.internal/private/name/golang/name?go-get=1: dial tcp 10.163.16.40:80: i/o timeout
  * "foo.internal.com/private-repo/subfolder/packageZ": unable to deduce repository and source type for "foo.internal.com/private-repo/subfolder/packageZ": unable to read metadata: go-import metadata not found

validateParams: could not deduce external imports' project roots

What did you expect to see?

A successful dep ensure that vendors all packages, using SSH to grab the internal ones.

Using v0.2.1 works.

What did you see instead?

A failed dep run with the above error, validateParams: could not deduce external imports' project roots

My Gopkg.toml has the following constraints for those repositories:

[[constraint]]
  name = "foo.internal.com/private-repo"
  source = "[email protected]:git/REPO/private-repo.git"

[[constraint]]
  name = "bar.internal/private/name"
  source = "[email protected]:private/name.git"

[sdboyer]

hi, thanks for the issue!

so, it's super weird that this would have worked under v0.2.1, but not now, and that that would be the problem. both versions depend on having a vanity imports metadata server to work. to my mind, the more likely issue is this:

dial tcp 10.163.16.40:80: i/o timeout

it seems like whatever service you're running for vanity import discovery may be down? or perhaps there's a network partition, or a firewall issue?

[slnt]

@sdboyer perhaps, but I tried with 0.2.1 minutes before getting that error message to confirm it was a problem between the version. It's also strange that it would be trying to get the package over HTTPS as it should be trying with SSH.

[sdboyer]

but I tried with 0.2.1 minutes before getting that error message to confirm it was a problem between the version.

huh. bizarre. i believe you're not the first person to report this, though - it's possible there'd a weird regression in that system, somewhere.

It's also strange that it would be trying to get the package over HTTPS as it should be trying with SSH.

right, so, that's actually a totally different thing. i know it seems like having this:

name = "foo.internal.com/private-repo"
source = "[email protected]:git/REPO/private-repo.git"

should be sufficient to identify that there's a git repo at the root identified by name. while it might be feasible for us to do that, that's not how things work currently. detailed exploration on that here: #860 (comment)

so, because the import path doesn't match any of the patterns dep knows (e.g. github.com/*, bitbucket.com/*, or anything with a *.git/* infix - these are the same set of patterns as go get), we still need to make an HTTP query to try to figure out what the root is. that's the network request that's timing out.

(also gonna close this out as a dupe of #860)