1

glide install在我的项目上运行时，出现以下错误：

[ERROR] Error scanning github.com/golang/protobuf/proto/testdata: cannot find package "." in:
    /Users/bevernie/.glide/cache/src/https-github.com-golang-protobuf/proto/testdata
[ERROR] Failed to retrieve a list of dependencies: Error resolving imports

在查看 protobuf 的源代码时，我实际上可以看到没有这样的包。但是，我不直接使用 protobuf，因此错误必须来自我使用的依赖项之一。

在我的项目上运行glide tree时，只有一个实例github.com/golang/protobuf/proto/testdata：

|-- github.com/golang/protobuf/proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
|   |-- github.com/golang/protobuf/proto/test_proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto/test_proto)
|   |   |-- (Recursion) github.com/golang/protobuf/proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
|   |-- github.com/golang/protobuf/ptypes/any   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
|   |   |-- (Recursion) github.com/golang/protobuf/proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
    github.com/golang/protobuf/proto/testdata   (glide get github.com/golang/protobuf/proto/testdata)
|-- github.com/golang/protobuf/ptypes/any   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
|   |-- github.com/golang/protobuf/proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
|   |   |-- github.com/golang/protobuf/proto/test_proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto/test_proto)
|   |   |   |-- (Recursion) github.com/golang/protobuf/proto   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
|   |   |-- (Recursion) github.com/golang/protobuf/ptypes/any   (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)

这并不能真正帮助我查明问题的根源。

您对如何解决这些问题有任何建议吗？

我的项目在一两个星期前编译得很好（我使用 Docker 在生产中部署，所以glide install每次都运行并且在此之前从未失败，而且我最近没有添加任何新的依赖项）。

4

1 回答 1

1

在您自己的PR (995)之前，有滑翔问题 968

看起来它是由存储库的结构更改引起的，即子包被移动或完全删除。

Elliot Wright ( seeruk)提出的解决方法：

如果已更新的包在您自己的控制之下，那么我发现使用一些较新的 Go 功能（如类型别名）更容易减轻重构带来的痛苦。
因此，不要只是移动一个包，而是移动它，然后在旧的新位置创建别名，这样你的旧代码仍然可以工作。
然后，逐渐将事情转移过来。基本上只是将事物标记为已弃用，但确保它们仍然可以使用一段时间，直到您移植新代码。

如果包不在您的控制范围内，那么您始终可以手动将您想要的版本克隆到您的供应商文件夹并在您的代码中进行更新。
完成后，Glide 应该让您再次更新。
如果它更复杂，有时在go get您完成更新包并依赖您的$GOPATH内容之前恢复使用会更容易。

这远非理想，但至少有一些方法可以解决它。
同时，我也在 dep 上提出了一个问题。
我认为他们正在研究一种禁用这种检查的方法，如果您只是希望该工具信任您作为开发人员。

因此，您可以使用godep甚至最前沿的vgo检查您是否有同样的问题。

于 2018-05-27T08:33:00.230 回答