Golang依赖管理工具Dep在本地开发中的使用

Golang依赖管理工具Dep在本地开发中的使用 我想这应该是关于这个issue的问题。

我有两个基础项目——一个工具项目和一个领域项目。另外还有14个项目需要其中一个或两个作为依赖项。我终于开始在我的项目中设置Dep，但立即就遇到了障碍。

似乎代码需要推送到远程仓库才能在dep ensure中被识别。这意味着工作流程会是：

  • 修改基础项目
  • 推送
  • 转到依赖基础项目的项目
  • dep ensure -update -v
  • 如果有bug，重新开始

如果我修改了基础包并导致依赖它的项目出现bug，我必须通过不断推送所做的修改来进行调试。然后我需要为每次修复尝试运行dep ensure -update，当确认问题已解决后，我必须在所有项目上运行dep ensure -update。这看起来真的是很大的开销。

希望我理解错了。作为有Java背景的人，我原本希望Dep能以类似Maven的方式工作——当项目构建时，将代码/二进制文件添加到单个本地仓库，所有其他项目都引用该仓库（$GOPATH/pkg/dep/sources似乎无法处理本地更改）。

目前看来，dep似乎不适合大型项目，我几乎要再次移除它。有没有人有解决方法（不涉及包装dep）？还是我做错了什么？

dep ensure -update -v

dep ensure -update

更多关于Golang依赖管理工具Dep在本地开发中的使用的实战教程也可以访问 https://www.itying.com/category-94-b0.html

7 回复

你需要明确排除它。请参阅此处的"ignored"部分：https://golang.github.io/dep/docs/Gopkg.toml.html

更多关于Golang依赖管理工具Dep在本地开发中的使用的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


谢谢。

它们位于同一个GOPATH中 - vendor目录具有优先权。明天我回去后会尝试移除dep依赖 - 可能我对dep init的信任度太高了。

你的做法不对。如果这些组件如此相互依赖，要么将它们保留在同一个代码仓库中，要么至少放在相同的GOPATH下，并通过dep工具排除依赖关系。

Dep 很棒，但在某些情况下，如果程序的某个部分由于某种原因位于不同的代码库中，并且需要同步演进时，它就会变得很麻烦。

我倾向于通过采用更大的代码库来避免这种情况。在我看来，如果某个部分要成为独立的代码库，至少应该能够在不需要将其拉入另一个代码库的情况下确定错误修复是否有效。

我们在发布前已经尝试过这个方法，但没有成功。

通过忽略这些包，也会忽略这些包中的依赖项。这导致父项目因缺少依赖而出现堆栈跟踪错误。例如，我有一个基础日志记录包——如果在 toml 文件中忽略该包，其他项目就无法访问日志记录器。如果不忽略该包，就会遇到前面描述的问题。

我暂时放弃了。感谢您的帮助。

从 toml 文件中移除约束并未产生预期效果（我记得昨天尝试过这个方法，但在回复前想再次确认一下）。

我在另一台电脑/全新检出环境中测试了这个建议，项目中仅存在 toml 文件（没有现有的锁定文件或供应商目录）。Dep ensure 仍然会将项目添加到供应商目录中，并且似乎没有根据项目的本地状态（无论是在提交变更之前还是之后）更新供应商目录。

我认为我的操作没有问题——目前 dep 的工作方式可能适用于单一/小型项目，但对于具有多个本地依赖项的项目来说使用起来不太方便。

我们昨天也考虑过使用更大的代码库，但我们的项目实际上都是功能完全独立的独立项目。仅仅为了让 dep 正常工作而调整我们的代码库结构，这种做法似乎有些短视/不妥。

感谢您的回复——在问题 935 解决之前，我可能会暂时撤回对 dep 的使用。

在Go语言中，Dep（dep）作为依赖管理工具，确实要求依赖项必须存在于远程仓库中才能被正确解析，这是其设计上的一个限制。对于本地开发，这会导致你描述的工作流程问题，增加调试和迭代的开销。不过，有几种方法可以缓解这个问题，而无需完全移除Dep。以下是一些专业建议和示例，基于Go生态系统的最佳实践。

使用replace指令在Gopkg.toml中覆盖依赖路径

Dep支持在项目的Gopkg.toml文件中使用replace指令，将远程依赖重定向到本地路径。这允许你在本地修改基础项目，而无需每次推送更改到远程仓库。具体步骤如下：

  1. 在依赖基础项目的每个项目的Gopkg.toml文件中，添加replace指令，指向本地的基础项目路径。
  2. 运行dep ensure来应用这些更改，使本地修改生效。

例如，假设你的基础项目是github.com/user/tool-project和github.com/user/domain-project，它们位于本地路径/path/to/local/tool-project和/path/to/local/domain-project。在依赖项目的Gopkg.toml中添加：

[[constraint]]
  name = "github.com/user/tool-project"
  version = "v1.0.0"

[[constraint]]
  name = "github.com/user/domain-project"
  version = "v1.0.0"

[replace]
  "github.com/user/tool-project" = "/path/to/local/tool-project"
  "github.com/user/domain-project" = "/path/to/local/domain-project"

然后运行：

dep ensure

这将使依赖项目使用本地的基础项目代码，而不是远程仓库。你可以在本地修改基础项目，并立即在依赖项目中测试，无需推送更新。当本地修改稳定后，你可以移除replace指令，推送基础项目到远程，并运行dep ensure -update来同步远程版本。

使用Go Modules作为替代方案（如果项目允许）

Dep已被Go官方弃用，推荐使用Go Modules（从Go 1.11开始内置）。Go Modules支持本地路径替换，更灵活地处理本地开发。如果你的项目可以迁移到Go Modules，可以避免Dep的限制。迁移步骤：

  1. 在项目根目录运行go mod init来初始化Go Modules。
  2. 使用replace指令在go.mod文件中指向本地路径。

例如，在依赖项目的go.mod文件中：

module your-dependent-project

go 1.16

require (
    github.com/user/tool-project v1.0.0
    github.com/user/domain-project v1.0.0
)

replace github.com/user/tool-project => /path/to/local/tool-project
replace github.com/user/domain-project => /path/to/local/domain-project

然后运行go mod tidy来同步依赖。这样，本地修改会立即反映在依赖项目中。

在Dep中使用本地vendor目录（如果必须坚持使用Dep）

如果项目必须使用Dep，你可以手动将本地基础项目复制到vendor目录，但这不推荐，因为它容易出错且难以维护。示例步骤：

  1. 在依赖项目中，运行dep ensure来生成vendor目录。
  2. 手动覆盖vendor中的基础项目代码为本地版本。
  3. 测试后，记得恢复vendor或更新远程依赖。

总结

Dep确实在本地开发中存在限制，但通过replace指令可以改善工作流程。长期来看，迁移到Go Modules是更好的选择，因为它提供了更强大的本地开发支持。根据你的项目环境，选择合适的方法来减少开销。如果你有更多具体问题，可以提供代码示例，我可以进一步帮助调试。

回到顶部