跨项目依赖管理的挑战

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《跨项目依赖管理的挑战》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

我有两个项目：

/myproject
/sharedproject

它们都是由 dep 管理的，我已经执行 go get -u github.com/golang/dep/cmd/dep 以获得最新的 dep 版本，并在两个项目上运行 dep ensure 。

当我运行 myproject 时，出现以下错误：

cannot use op (type *"myproject/vendor/github.com/go-openapi/spec".Operation) as type *"sharedproject/vendor/github.com/go-openapi/spec".Operation

出了什么问题以及如何解决这个问题？

解决方案

看起来情况是 sharedproject 提供 github.com/go-openapi/spec 依赖项，而 myproject 从github.com/go-openapi/spec获取sharedproject和依赖项 GOPATH。

现在，当您在 sharedproject 中引用 github.com/go-openapi/spec 时，它指的是 供应商目录中的包，在技术上与 GOPATH 中的相同包，即使两者具有相同的内容。所以当你通过一个 *github.com/go-openapi/spec.Operation 类型的变量从 myproject 到 a sharedproject中的函数，类型包与预期不符，编译失败。

要解决此问题，请确保 sharedproject 在 myproject 内提供。什么时候 您执行此操作，dep 确保 将放置 sharedproject 的副本，而无需其供应商 目录进入 myproject 的供应商目录。此后，myproject 和 sharedproject 都将使用 github.com/go-openapi/spec 包（来自 myproject 的供应商目录）。

如果您经常更改 sharedproject 并且想要，这确实会使本地开发变得困难 立即在 myproject 中使用这些更改（在将更改推送到 Git 远程之前无法使用 dep）。我会通过复制来解决这个问题 手动将 sharedproject 放入 myproject 的供应商目录中，而不使用 dep （当然不包括供应商目录）。但请注意不要将那些手动复制的更改提交到 Git！

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《跨项目依赖管理的挑战》文章吧，也可关注golang学习网公众号了解相关技术文章。