在Go 1.7中使用嵌套的供应商目录

Question

I have a go project having the following packages:-

go list ./... | grep -v /vendor/ 

github.com/jab/JSes
github.com/jab/JSes/src/common/config
github.com/jab/JSes/src/common/logger
github.com/jab/JSes/src/common/monitor
github.com/jab/JSes/src/handlers/healthcheck
github.com/jab/JSes/src/handlers/sessionuser
github.com/jab/JSes/src/test/servicetest

All external dependensies are added inside the vendor folder:-

vendor/
    bitbucket.org
        m
          ses-ser

Now the ses-ser is having the following packages:-

ses-ser
    vendor   //Contains all the external dependencies
    api
    constants
    exceptions
    idgen
    jsonDecoder
    log
    model
    monitor
    persistence
    redis
    routes
    src/bddtest/servicetest
    util

The Makefile looks like below:-

.PHONY: deploy

LOGLEVEL ?= 2
GOFLAGS ?= $(GOFLAGS:)

PKG = $(shell go list ./... | grep -v /vendor/ | tr "
" " ")
PWD = $(shell pwd)

export GOPATH = $(PWD):$(shell echo $$GOPATH)
export GOBIN = $(PWD)/bin
export GOROOT = $(shell echo $$GOROOT)

deploy: clean format build install conf

build:
    @rm -rf pkg/ 2>/dev/null
    @rm -rf _libs/pkg/ 2>/dev/null
    @go build $(GOFLAGS) $(PKG)

But on doing make build I am getting the below panic:-

jab-MacBook-Pro-4:JSe debraj$ make build
panic: runtime error: slice bounds out of range

goroutine 1 [running]:
panic(0x3e1b40, 0xc420010130)
    /usr/local/go/src/runtime/panic.go:500 +0x1a1
main.vendoredImportPath(0xc4203df200, 0xc42037f301, 0x2f, 0x3, 0xc41fff4f00)
    /usr/local/go/src/cmd/go/pkg.go:463 +0x66c
main.loadImport(0xc42037f301, 0x2f, 0xc4201605b0, 0x64, 0xc4203df200, 0xc4201c99e0, 0xc42022f680, 0x1, 0x1, 0x1, ...)
    /usr/local/go/src/cmd/go/pkg.go:333 +0x9ea
main.(*Package).load(0xc4203df200, 0xc4201c99e0, 0xc420298e00, 0x0, 0x0, 0x4)
    /usr/local/go/src/cmd/go/pkg.go:940 +0x12b6
main.loadImport(0xc420356f01, 0x29, 0xc4203203c0, 0x45, 0xc4203de480, 0xc4201c99e0, 0xc4203570e0, 0x1, 0x1, 0x1, ...)
    /usr/local/go/src/cmd/go/pkg.go:374 +0x470
main.(*Package).load(0xc4203de480, 0xc4201c99e0, 0xc420293c00, 0x0, 0x0, 0x4)
    /usr/local/go/src/cmd/go/pkg.go:940 +0x12b6
main.loadImport(0xc42019c6b1, 0xd, 0xc42019e7c0, 0x33, 0xc4201ac480, 0xc4201c99e0, 0xc420192e70, 0x1, 0x1, 0x1, ...)
    /usr/local/go/src/cmd/go/pkg.go:374 +0x470
main.(*Package).load(0xc4201ac480, 0xc4201c99e0, 0xc420185180, 0x0, 0x0, 0xc)
    /usr/local/go/src/cmd/go/pkg.go:940 +0x12b6
main.loadImport(0x7fff5fbff891, 0x1a, 0xc420018044, 0x33, 0x0, 0xc4201c99e0, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/local/go/src/cmd/go/pkg.go:374 +0x470
main.loadPackage(0x7fff5fbff891, 0x1a, 0xc4201c99e0, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:1658 +0x28f
main.packagesAndErrors(0xc420152c80, 0x7, 0x7, 0xc42019c520, 0x20, 0x3f3e60)
    /usr/local/go/src/cmd/go/pkg.go:1703 +0x337
main.packagesForBuild(0xc42000c0b0, 0x7, 0x7, 0x493df8, 0xc420018180, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:1719 +0x75
main.runBuild(0x628540, 0xc42000c0b0, 0x7, 0x7)
    /usr/local/go/src/cmd/go/build.go:440 +0xd4
main.main()
    /usr/local/go/src/cmd/go/main.go:181 +0x624
make: *** [build] Error 2

This seems to be related to 16656 which will be fixed in Go 1.8.

As a workaround I tried to put all the external dependencies under _libs. And modified my $GOPATH in Makefile like below:-

export GOPATH = $(PWD)/_libs:$(PWD)/_libs/src/bitbucket.org/m/ses-ser/vendor:$(PWD):$(shell echo $$GOPATH). 

But then it started giving me error like below:-

src/handlers/healthcheck/health_check.go:23: cannot use func literal (type func(*"github.com/valyala/fasthttp".RequestCtx)) as type func(*"bitbucket.org/m/ses-ser/vendor/github.com/valyala/fasthttp".RequestCtx) in field value

Can someone suggest someway of getting around this issue?

Environment:-

• go version go1.7.3 darwin/amd64
• Mac OS X - Version 10.11.6

Answer 1

While the build panic was a bug which has been fixed, having nested vendor directories will cause type conflicts between packages.

You should only have a single vendor directory for your project. If any of your dependencies have vendor directories of their own, they should be stripped out and combined into your single top-level vendor directory.

Tools designed to vendor your dependencies should do this for you.