如何避免用`go get`更新自己 [英] How to avoid updating myself with `go get`

问题描述

我有一个像这样的包结构:

  GOPATHsrcgithub.com/myname我的主项目something.go//从github导入东西我的子项目main.go//导入"github.com/myname/mymainproject"和其他 

作为m build的一部分，我从主目录中运行 go -u -t ./...如果从master构建，这很好用，但是我将jenkins配置为从任何分支构建.

但是，从另一个分支进行构建时，当它更新 mysubproject 的依赖项时，会将整个工作目录更新为master，这不是我想要的.

我只有两个可能可行的真实想法:

1. 我运行 go get 后，签出要构建的原始分支.我仍然担心在go-get中切换分支可能会导致它跳过仅存在于分支中的某些依赖项，或者不必要地获取仅存在于master中的依赖项，因此我不确定这是否是一个好的解决方案.
2. 使用神奇的 go1 标记在分支上标记当前提交.我相信这也必须在遥控器上完成，这使得它的吸引力大大降低.

有什么方法可以防止go-get接触我的主存储库吗?

解决方案

虽然我不建议将 go get -u 用作生产版本的一部分(例如Google，但我建议将软件包打包出售，这样您可以重现旧版本并在分支上管理软件包的版本控制)，使用 list 和一些过滤器的小脚本来获取所需的内容并不难.这样的事情应该起作用:

  go get -u -t`go list./... |grep -v mysubproject` 

这将排除 mysubproject .或者，您可以排除 mymainproject ，或者进行其他过滤以摆脱您不想更新的内容.

您还应该查看 godep ，以帮助您管理依赖关系并在需要时进行更新.

---

更新:您可以将其带到另一个级别，并明确列出您导入的所有软件包:

 转到列表-f'{{join .Imports"\ n"}}'github.com/mymainproject/mysubproject |排序-u 

这列出了mysubproject直接导入的所有内容.您可以过滤出mymainproject，然后更新该列表(其中不包括mysubproject或mymainproject".它也包括系统软件包，但是这些软件包不会更新，因此没关系(尽管您可以根据需要过滤它们)./p>

Godep当前正在添加一个 -r 选项，该选项将重写导入，因此您可以将依赖项供应到树中，并将其作为 github.com/mymainproject/mysubproject/Godeps/导入._workspace/src/github.com/< package> .这是在 rewrite 分支上.这种方法的优势在于，这意味着您的库使用的是您测试过的版本，而不是最终用户计算机上使用的任何版本.不利之处在于最终消费者可能会获得同一包装的多个副本.

您应该始终像这样的时间问自己是否真的需要库中的依赖项.传递依存关系似乎具有永无止境的此类问题.您可以解决它们，并且应该使用对您来说确实很重要的依赖关系，但是我不止一次选择了我实际需要的两个函数并将它们复制到包中以避免依赖关系.我并不是说重用代码是不好的；只需确保每种情况下的成本都值得.

I have a package structure that looks like this:

GOPATH
   src
      github.com/myname
         mymainproject
            something.go //imports things from github
            mysubproject
               main.go //imports "github.com/myname/mymainproject" + others

As part of m build I run, go get -u -t ./.. from the main directory. This works great if building from master, but I have jenkins configured to build from any branch.

When building from another branch though, when it updates dependencies of mysubproject it updates the full working directory to master, which is very much not what I want.

I only have two real ideas that might work:

1. After I run go get, check out the original branch that I want to build. I still worry that switching branches mid go-get could cause it to skip some dependencies that exist only in the branch, or fetch unnecessarily ones that exist only in master, so I'm not sure this is a good solution.
2. Tag the current commit on the branch with the magic go1 tag. I believe this would have to be done on the remote as well, which makes it much less appealing.

Is there any way to prevent go-get from touching my main repository?

解决方案

While I don't recommend go get -u as part of a production build (like Google, I recommend vendoring your packages so you can reproduce old builds and manage package versioning on branches), it's not that hard to get what you want with a small script using list and some filtering. Something like this should work:

go get -u -t `go list ./... | grep -v mysubproject`

That would exclude mysubproject. Or you could exclude mymainproject, or otherwise filter to get rid of whatever you don't want to update.

You should also look at godep to help you manage your dependencies and update them when you mean to.

---

UPDATE: You can take this to another level and explicitly list all the packages that you import:

go list -f '{{join .Imports "\n"}}' github.com/mymainproject/mysubproject | sort -u

This lists everything that mysubproject directly imports. You can filter out mymainproject and then update that list (which won't include mysubproject or mymainproject". This includes system packages, too, but those won't update, so it's ok (though you could filter them if you wanted).

Godep is currently adding a -r option that will rewrite imports, so you can vendor your dependencies into your tree, and import them as github.com/mymainproject/mysubproject/Godeps/_workspace/src/github.com/<package>. This is on the rewrite branch. The advantage of this approach is that it means your library uses the version you tested with rather than whatever version happens to be on the final consumer's machine. The downside is that the final consumer may wind up with multiple copies of the same package.

You should always take times like these to ask yourself if you really need the dependency in your library. Transitive dependencies have seemingly never-ending problems like these. You can work around them, and you should for a dependency that is really important to you, but I've more than once picked up the two functions I actually needed and copied them into my package to avoid a dependency. I'm not saying reusing code is bad; just make sure the cost is worth it in each case.

这篇关于如何避免用`go get`更新自己的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！