Dep: "unable to read metadata" error

Created on 13 Jun 2017  路  6Comments  路  Source: golang/dep

Ran dep init in github.com/kubernetes/kubernetes repo. After godep import phase in init, gps solver failed with error:

panic: shouldn't be possible unable to deduce repository and source type for "k8s.io/apiextensions-apiserver/examples/client-go/apis/cr/v1": unable to read metadata: go-import metadata not found

goroutine 1 [running]:
github.com/golang/dep/internal/gps.(*solver).selectRoot(0xc420969c20, 0xc420b72bd0, 0x0)
    /Users/sunny/go/src/github.com/golang/dep/internal/gps/solver.go:549 +0xb50
github.com/golang/dep/internal/gps.(*solver).Solve(0xc420969c20, 0x36, 0x16b5300, 0xc4207ea000, 0xc42001015a)
    /Users/sunny/go/src/github.com/golang/dep/internal/gps/solver.go:394 +0x8d
main.(*initCommand).Run(0xc42016d99a, 0xc4200b1630, 0xc42008e170, 0x0, 0x0, 0x0, 0x0)
    /Users/sunny/go/src/github.com/golang/dep/cmd/dep/init.go:147 +0x5f3
main.(*Config).Run(0xc420076fc0, 0xc420076fc0)
    /Users/sunny/go/src/github.com/golang/dep/cmd/dep/main.go:160 +0x980
main.main()
    /Users/sunny/go/src/github.com/golang/dep/cmd/dep/main.go:45 +0x253
bug

All 6 comments

haha https://github.com/golang/dep/blob/master/internal/gps/solver.go#L548 馃榾

this could well happen; handle it with a more graceful error

I was just chatting with @sttts about if k8's could try out the importer now that we support godep. He mentioned that k8's does some "fixing" after running godep, and that the revisions in the godep lock may not be the actual revs used during a build. So it sounds like more work would be necessary (beyond the staging issue).

Actually, the kube godep-save.sh is still pretty sane: https://github.com/kubernetes/kubernetes/blob/master/hack/godep-save.sh

OpenShift's has plenty of workarounds for godeps: https://github.com/openshift/origin/blob/master/hack/godep-save.sh (178 lines of bash). Vendoring kube will be the real challenge.

Will give the new import a try after my vacation.

About the error: apiextensions-apiserver is not synched yet to the real github repo. It's staging only until our sync bot is updated.

https://k8s.io/apiextensions-apiserver/examples/client-go/apis/cr/v1?go-get=1 doesn't return valid meta tags, so dep doesn't know how to find the repository.

edit: I thought we handled the error instead of panicing... I'll go look for that PR.
edit 2: Found it. #697 is still not merged. It needs an update but it should handle this panic and print an appropriate error message instead.

that the revisions in the godep lock may not be the actual revs

I double checked what we check in nowadays into the lock files: the staging repos are all filtered out in the main Godeps.json, so they are not wrong, but just missing. The staging directories have fake sha1s, e.g. https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/Godeps/Godeps.json, but dep will probably not care about those. Hence, dep will pick up the staging dependencies from the import lines only. This might even work with kube master branch

  • as long as the nightly sync version of the staging repos work with kube master
  • and as soon as k8s.io/apiextensions-apiserver is properly synched and got metadata.

Sorry, #697 not being merged is the cause of the panic here (though the underlying issue remains). Working on pushing that forward 馃槃

closing this, with #697 done - at least, this panic shouldn't occur for those reasons anymore.

Was this page helpful?
0 / 5 - 0 ratings