This problem with dep failing was reported to me as the author of a Go package, see here.
I've looked into the cause and reporting it here because it seems like a bug in dep.
dep are you using (dep version)?The latest via go get -u github.com/golang/dep/cmd/dep as of right now, commit https://github.com/golang/dep/commit/66ec1e8481a55619ede9280d8ae5449247395059. Running git describe --tags reports v0.5.1-3-g66ec1e84.
dep command did you run?$ dep init
$ cat >main.go <<EOF
package main
import "fmt"
import "dmitri.shuralyov.com/text/kebabcase"
func main() {
fmt.Println(kebabcase.Parse("foo-bar-baz").ToMixedCaps())
}
EOF
$ dep ensure -v
Successful operation.
$ dep ensure -v
The following errors occurred while deducing packages:
* "dmitri.shuralyov.com/text/kebabcase": unable to deduce repository and source type for "dmitri.shuralyov.com/text/kebabcase": unable to read metadata: multiple meta tags match import path "dmitri.shuralyov.com/text/kebabcase"
validateParams: could not deduce external imports' project roots
The Go package at the vanity import path dmitri.shuralyov.com/text/kebabcase currently has two go-import meta tags, one with the VCS type "git" telling the go command where to clone the containing repository via git, and another with the type "mod" telling the go command what Go module proxy can be used to fetch the module.
The "mod" go-import meta import is documented at the bottom of https://golang.org/cmd/go/#hdr-Import_path_syntax section.
The "mod" meta tag seems to be causing dep to think there are two VCS types and it throws the above error. If dep doesn't have full support the "mod" meta tag, it should be skipping over it instead of reporting an error.
The go command has no problems with fetching that module, both in Go 1.12 and Go 1.11.
The problem in code is inside the parseMetaGoImports function:
https://github.com/golang/dep/blob/66ec1e8481a55619ede9280d8ae5449247395059/gps/discovery.go#L58-L70
The fix should be as little as:
continue
}
if f := strings.Fields(attrValue(e.Attr, "content")); len(f) == 3 {
+ // Ignore VCS type "mod", which is applicable only in module mode.
+ if f[1] == "mod" {
+ continue
+ }
imports = append(imports, metaImport{
Prefix: f[0],
VCS: f[1],
This issue and the fix for it are very similar to issue https://github.com/golang/go/issues/31845 that was affecting the golang.org/x/tools/go/vcs package and the CL 175219 that resolved it.
I understand this is small and the fix is trivial, but it's still annoying how tools that used to work OK now suddenly need more investment in order to behave the same way that they did before. I thought the whole point of Go was to preserve compatibility, etc.
I’ve sent PR #2152 that resolves this issue.
I tested it on the package in the original issue report, and dep ensure was able to run successfully after the change.
The following repo includes a Makefile that can target __linux__ and __macOS__ platforms
It will clone the dep repo, apply the patch, build and install the patched dep to both /usr/local/bin and $GOPATH/bin.
This make it easier for us to deploy this fix in our automated builds.
It goes without saying but I will say it: __Use at your own risk.__
You may have to modify the Makefile for your needs. It will replace your current dep entirely. You may need elevated privileges to perform the install step.
The fix has been merged to master branch.
It hasn't been included in a released version yet, but it can be installed right now from source code via go get -u github.com/golang/dep/cmd/dep (as described at the bottom of https://github.com/golang/dep#installation).
I've confirmed the original issue is resolved with the latest version:
$ dep init
$ cat >main.go <<EOF
package main
import "fmt"
import "dmitri.shuralyov.com/text/kebabcase"
func main() {
fmt.Println(kebabcase.Parse("foo-bar-baz").ToMixedCaps())
}
EOF
$ dep ensure -v
# Gopkg.lock is out of sync with Gopkg.toml and project imports:
dmitri.shuralyov.com/text/kebabcase: imported or required, but missing from Gopkg.lock's input-imports
Root project is "example.com/p"
1 transitively valid internal packages
1 external packages imported from 1 projects
(0) ✓ select (root)
(1) ? attempt dmitri.shuralyov.com/text/kebabcase with 1 pkgs; 1 versions to try
(1) try dmitri.shuralyov.com/text/kebabcase@master
(1) ✓ select dmitri.shuralyov.com/text/kebabcase@master w/1 pkgs
(2) ? attempt github.com/shurcooL/graphql with 1 pkgs; 1 versions to try
(2) try github.com/shurcooL/graphql@master
(2) ✓ select github.com/shurcooL/graphql@master w/1 pkgs
✓ found solution with 2 packages from 2 projects
Solver wall times by segment:
b-source-exists: 940.112035ms
b-list-versions: 825.797845ms
b-list-pkgs: 324.933011ms
b-gmal: 317.304225ms
new-atom: 185.314µs
select-atom: 134.555µs
select-root: 129.1µs
satisfy: 122.941µs
b-deduce-proj-root: 39.599µs
other: 24.658µs
TOTAL: 2.408783283s
# Bringing vendor into sync
(1/2) Wrote github.com/shurcooL/graphql@master: new project
(2/2) Wrote dmitri.shuralyov.com/text/kebabcase@master: new project
$ echo $?
0
Most helpful comment
The problem in code is inside the
parseMetaGoImportsfunction:https://github.com/golang/dep/blob/66ec1e8481a55619ede9280d8ae5449247395059/gps/discovery.go#L58-L70
The fix should be as little as:
This issue and the fix for it are very similar to issue https://github.com/golang/go/issues/31845 that was affecting the
golang.org/x/tools/go/vcspackage and the CL 175219 that resolved it.