嘿，谁能给我解释一下 docker go-wrapper 应该做什么？
https://github.com/docker-library/golang/blob/master/go-wrapper
在这条评论之后:
This script allows us to take a generic directory of Go source files such as "/go/src/app" and determine that the canonical "import path" of where that code expects to live and reference itself is "github.com/jsmith/my-cool-app". It will then ensure that "/go/src/github.com/jsmith/my-cool-app" is a symlink to "/go/src/app", which allows us to build and run it under the proper package name.
我知道，如果我在我的 github go 路径下开发一个项目，然后将它安装在 docker 容器中的 /go/src/app 中，导入仍然保持不变(github 导入)对吗？
COPY . /go/src/app
WORKDIR /go/src/app
RUN go-wrapper download
RUN go-wrapper install
然而，当我尝试使用 dep 与 vendor 一起安装/运行时
go get -u github.com/golang/dep/cmd/dep
dep init
dep ensure -update
它会将我的存储库下载到 vendor ，然后尝试从那里导入它，这是为什么？
最佳答案
我不熟悉 dep，所以我无法对您问题的那部分发表评论。但是，您引用的文本与规范导入路径有关，并且您没有说您使用的是规范导入路径。您必须使用规范的导入路径来使 go-wrapper 的行为与引用中描述的一样。
一旦你的包有一个规范的导入路径(比如 package main//import "github.com/user/projname")然后 go-wrapper 将识别那个特殊的注释并创建一个从 go/src/github.com/user/projname 到 /go/src/app inside docker 容器的符号链接(symbolic link)。此符号链接(symbolic link)将阻止 go-wrapper download 从远程 (github.com) 下载子包，如 github.com/user/projname/subpackage。
当我在本地开发时，这种行为对我特别有用，因为我想在将它们提交到远程之前测试我对子包的本地更改。如果 go-wrapper 没有为我创建符号链接(symbolic link)，那么它将转到远程并下载每个子包，这意味着我将获得旧版本而不是本地编辑的子包.
关于docker - docker go-wrapper 脚本如何工作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46923537/