Hi,
I know these topics have been discussed countless times on this list
so I apologize in advance if I missed an existing thread when trying
to find an answer.
At work we're using a vendoring approach for third-party dependencies.
Our tree looks like:
├── bin
├── pkg
└── src
├── _vendor
│ ├── bin
│ ├── pkg
│ └── src
│ ├── bitbucket.org
│ │ ├── ...
│ ├── code.google.com
│ │ └── ...
│ ├── github.com
│ │ ├── ...
│ └── gopkg.in
│ └── v1
│ └── ...
├── config
├── datastore
├── monitoring
└── ...
We've put all third-party code into src/_vendor/src and set our GOPATH
to $(topdir):$(topdir)/src/_vendor. We're using goven to manage
_vendor, which rewrites the URLs accordingly, e.g.:
index e4fd7a4..1e3fd76 100644
--- a/go/src/_vendor/src/github.com/GeertJohan/go.rice/box.go
+++ b/go/src/_vendor/src/github.com/GeertJohan/go.rice/box.go
import (
- "github.com/GeertJohan/go.rice/embedded"
+ "_vendor/src/github.com/GeertJohan/go.rice/embedded"
I've been debugging an obscure error with go.rice which only manifests
when running our unit tests with the -cover flag. I isolated the issue
and realized that I had duplicate package binaries, some in pkg and
some in _vendor/:
$ find . -name embedded.a
./pkg/darwin_amd64/_vendor/src/github.com/GeertJohan/go.rice/embedded.a
./src/_vendor/pkg/darwin_amd64/github.com/GeertJohan/go.rice/embedded.a
along with inconsistent import paths to match, with some code
importing relative to $(topdir) and some relative to
$(topdir)/src/_vendor. That was fun to debug.
My question is about the interaction of GOPATH and _vendor. It seems
an odd mixture (and a bug?) for us to include both $(topdir) and
$(topdir)/src/_vendor in GOPATH and *also* to rewrite all the imports
relative to $(topdir). Should all our imports just be rewritten
relative to $(topdir) and GOPATH simply set to $(topdir)? Or should
our imports be left alone and GOPATH set to
$(topdir):$(topdir)/src/_vendor, like it is now?
At a higher level I'm wondering what it means conceptually to have
multiple dirs in GOPATH. How do commands like go-get and go-install
determine where to drop their artifacts? go help importpath says:
New downloaded packages are written to the first directory
listed in the GOPATH environment variable (see 'go help gopath').
and a similar detail in 'go help gopath' but I'm confused about where
the static libs end up during a build.
Thanks,
brian
I know these topics have been discussed countless times on this list
so I apologize in advance if I missed an existing thread when trying
to find an answer.
At work we're using a vendoring approach for third-party dependencies.
Our tree looks like:
├── bin
├── pkg
└── src
├── _vendor
│ ├── bin
│ ├── pkg
│ └── src
│ ├── bitbucket.org
│ │ ├── ...
│ ├── code.google.com
│ │ └── ...
│ ├── github.com
│ │ ├── ...
│ └── gopkg.in
│ └── v1
│ └── ...
├── config
├── datastore
├── monitoring
└── ...
We've put all third-party code into src/_vendor/src and set our GOPATH
to $(topdir):$(topdir)/src/_vendor. We're using goven to manage
_vendor, which rewrites the URLs accordingly, e.g.:
index e4fd7a4..1e3fd76 100644
--- a/go/src/_vendor/src/github.com/GeertJohan/go.rice/box.go
+++ b/go/src/_vendor/src/github.com/GeertJohan/go.rice/box.go
import (
- "github.com/GeertJohan/go.rice/embedded"
+ "_vendor/src/github.com/GeertJohan/go.rice/embedded"
I've been debugging an obscure error with go.rice which only manifests
when running our unit tests with the -cover flag. I isolated the issue
and realized that I had duplicate package binaries, some in pkg and
some in _vendor/:
$ find . -name embedded.a
./pkg/darwin_amd64/_vendor/src/github.com/GeertJohan/go.rice/embedded.a
./src/_vendor/pkg/darwin_amd64/github.com/GeertJohan/go.rice/embedded.a
along with inconsistent import paths to match, with some code
importing relative to $(topdir) and some relative to
$(topdir)/src/_vendor. That was fun to debug.
My question is about the interaction of GOPATH and _vendor. It seems
an odd mixture (and a bug?) for us to include both $(topdir) and
$(topdir)/src/_vendor in GOPATH and *also* to rewrite all the imports
relative to $(topdir). Should all our imports just be rewritten
relative to $(topdir) and GOPATH simply set to $(topdir)? Or should
our imports be left alone and GOPATH set to
$(topdir):$(topdir)/src/_vendor, like it is now?
At a higher level I'm wondering what it means conceptually to have
multiple dirs in GOPATH. How do commands like go-get and go-install
determine where to drop their artifacts? go help importpath says:
New downloaded packages are written to the first directory
listed in the GOPATH environment variable (see 'go help gopath').
and a similar detail in 'go help gopath' but I'm confused about where
the static libs end up during a build.
Thanks,
brian