英文:
A single or multiple gopaths for multiple projects using godep
问题
目前我正在使用godep来进行Go语言的包管理。问题是，我正在同时开发多个项目，这些项目依赖于不同版本的某个包。我无法决定如何组织我的GOPATH。我有几个选项：
- 使用单个GOPATH，在切换项目时使用godep restore。这样可以切换不同版本的特定包。
- 每个项目使用一个GOPATH，只在需要时使用godep restore。
哪个选项是推荐的，为什么呢？
英文:
Currently I'm using godep for package vendoring for Go. The problem is that I'm working on multiple projects depending on different versions of a certain package. I can't decide how to structure my GOPATH(s). I have several options:
- Use a single GOPATH and use godep restore when switching between projects. The different versions of the certain package will be switched.
- Use a GOPATH per project and only use godep restore when needed.
Which option is recommended and why?
答案1
得分: 1
我建议为每个项目使用一个GOPATH，以更好地隔离每个依赖项，并确保没有混淆依赖项。
在每个GOPATH中，您仍然可以使用您选择的依赖管理器。
即使使用了vendoring（只是为了确保获得独立的工作空间），我也会使用这种方法。
对于vendoring（Go 1.5+），我使用**govendor**，通常的做法是：
govendor fetch +m
使用govendor fetch从远程获取新的依赖项或更新现有的依赖项。
英文:
> I'm working on multiple projects depending on different versions of a certain package
Then I would recommend a GOPATH per project, in order to better isolate each dependencies, and make sure there isn't any mix_up in said dependencies.
Within each GOPATH, you still can use the dependency manager of your choice.
I use that even with vendoring (just to be sure to get an independent workspace)
For vendoring, (Go 1.5+), I use govendor, typically:
govendor fetch +m
> Pull in new dependencies or update existing dependencies directly from remotes with govendor fetch.
答案2
得分: 0
这是一个注释，自从1.5版本以及Go语言中引入了vendoring功能后，这已经过时了。
英文:
As a note, this has been obsolete since 1.5 and the advent of vendoring in Go.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论