docker go-wrapper脚本如何工作

Question

hey can anyone explain to me what docker go-wrapper should do ? https://github.com/docker-library/golang/blob/master/go-wrapper following this comment:

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.

I understand that if I am developing a project under mine github go path then mounting it /go/src/app inside a docker container will work with imports still remained unchanged (github imports) correct ?

COPY . /go/src/app
WORKDIR /go/src/app

RUN go-wrapper download
RUN go-wrapper install

however when i try to install/run with vendors using dep

go get -u github.com/golang/dep/cmd/dep
dep init
dep ensure -update

it downloads my repo to vendor and then tries to import it from there why is that ?

Answer 1

I'm not familiar with dep so I cannot comment on that part of your problem. However, the text you quoted relates to the canonical import path and you did not say you are using a canonical import path. You MUST use a canonical import path to get go-wrapper to behave like described in the quote.

Once your package has a canonical import path (like package main // import "github.com/user/projname") then go-wrapper will recognize that special comment and create a symlink from go/src/github.com/user/projname to /go/src/app inside the docker container. This symlink will prevent go-wrapper download from downloading sub-packages like github.com/user/projname/subpackage from the remote (github.com).

This behavior is especially useful for me when I am developing locally because I want to test my local changes to sub-packages before I commit them to the remote. If go-wrapper did not symlink for me, then it would go to the remote and download each of the sub-packages, which means I would be getting the older version instead of my locally edited sub-packages.