State of vendoring in 1.6.1?

[titpetric]

I'm trying to start with vendoring and Go 1.6.1, but I'm having issues in the sense that my vendor folder isn't getting picked up:

root@b7f75d02a32f:/go# go run flags.go
flags.go:3:8: cannot find package "github.com/namsral/flag" in any of:
        /usr/local/go/src/github.com/namsral/flag (from $GOROOT)
        /go/src/github.com/namsral/flag (from $GOPATH)
root@b7f75d02a32f:/go# GO15VENDOREXPERIMENT=1 go run flags.go
flags.go:3:8: cannot find package "github.com/namsral/flag" in any of:
        /usr/local/go/src/github.com/namsral/flag (from $GOROOT)
        /go/src/github.com/namsral/flag (from $GOPATH)
root@b7f75d02a32f:/go# find -type d -name flag
./vendor/github.com/namsral/flag
root@b7f75d02a32f:/go# go version
go version go1.6.1 linux/amd64
root@b7f75d02a32f:/go#

From what I understood, I should never use '/vendor/' in import paths, so I'm using this:

import "github.com/namsral/flag"

but with no success. Any ideas what's going on here? I created the vendor/ folder with gvt fetch (using justin cormacks docker image from docker hub).

[titpetric]

p.s. doing a simple mv vendor src makes the flags.go run fine. Is this a problem with the go build? Or perhaps some missing ENV path?

[justincormack]

Yes, Go is expecting this to be under /go/src. I normally run the container with docker run -v $PWD:/go/src justincormack/gvt fetch github.com/...

[titpetric]

@justincormack I'm using golang:latest which expects it under /go (but i've adapted gvt docker run to use /go/src). Gvt works fine, go works fine, I just can't get go to acknowledge the vendor/ folder when using go run/go build.

To reproduce:

#!/bin/bash

rm -rf vendor

cat << EOF > flags.go
package main

import "github.com/namsral/flag"
import "fmt"
import "os"

func main() {
        fs := flag.NewFlagSetWithEnvPrefix(os.Args[0], "GO", 0)
        var (
                port = fs.Int("port", 8080, "Port number of service")
        )
        fs.Parse(os.Args[1:])

        fmt.Printf("Server port: %d\n", *port)
}

EOF

docker run --rm -v `pwd`:/go/src justincormack/gvt fetch github.com/namsral/flag
docker run --rm -v `pwd`:/go golang:latest go run flags.go
docker run --rm -v `pwd`:/go golang:latest go version

Prints:

flags.go:3:8: cannot find package "github.com/namsral/flag" in any of:
        /usr/local/go/src/github.com/namsral/flag (from $GOROOT)
        /go/src/github.com/namsral/flag (from $GOPATH)
go version go1.6.1 linux/amd64

Expected:

Server port: 8080
go version go1.6.1 linux/amd64

What am I missing?

[justincormack]

docker run --rm -vpwd:/go golang:latest go run flags.go is binding in the current directory at /go so there is no /go/src directory. I think you should be using pwd:/go/src in all three cases.

[titpetric]

Slight issue with WORKDIR set to /go and not /go/src in golang Dockerfile? Testing.

Nope, same result:

docker run --rm --workdir="/go/src" -e GOPATH=/go/src -v `pwd`:/go/src golang:latest go run flags.go

Seems golang:latest is fine with /go, it's the default workdir for it. I will try to override gvt entrypoint and run go from your image, to see if it's different.

[titpetric]

@justincormack - slightly evil repro even with gvt image:

docker run --rm -v `pwd`:/go/src --entrypoint /usr/bin/env justincormack/gvt go run flags.go

Same go version, go version go1.6.1 linux/amd64. I'm sorry, it seems like it must/should work, I just have no idea why it doesn't and I hoped an extra pair of eyes will notice something.

[titpetric]

I'm also having no joy against the 1.5 branch:

docker run --rm -e GO15VENDOREXPERIMENT=1 -v `pwd`:/go golang:1.5 go run flags.go
docker run --rm -e GO15VENDOREXPERIMENT=1 -v `pwd`:/go golang:1.5 go version

The above runs only if I mv vendor src. I have little hair left :)

[titpetric]

Update: -v pwd:/go/src/flags/ -w /go/src/flags/ - starts working with vendor/ dir.

I have no idea why /app for example doesn't, while with simple helloworld.go, run/build works.

[justincormack]

No its not that, the problem is if you docker run -v $PWD:/go there will be nothing in /go/src any more as you overwrote it with the bind mount. Do docker run -it --rm -e GO15VENDOREXPERIMENT=1 -vpwd:/go sh and look around at the file system.

[justincormack]

Put the code anywhere under /go/src and you should be fine...

[titpetric]

@justincormack I can confirm that /go/src/folder works, but /go/src/ not. Also /app doesn't work, but I guess this is just some rule about how you need to layout go source files? I'm amazed that 'go run' worked for me up until this point :)

[justincormack]

Yes, Go is very (annoyingly) fussy. /go/src/app is where it should be.

[titpetric]

Something doesn't track here. I was using -v pwd:/go for a few weeks and go run and go build worked as expected. pwd/src became /go/src and every package I pulled with go get was in /go/src/github.com/.... Not ideal I guess, but everything worked.

And now if to mount under /go/src/app, it would become /go/src/app/src. Vendor/ dir would be in /go/src/app/src/vendor/ and would work for /go/src/app/src/main.go - but it wouldn't work for a subpackage. If I have a subpackage "proxy" (import "./proxy") it will not find the package from the root vendor/, and it will not find a package inside /go/src/app/src/proxy/vendor either.

proxy/proxy.go:7:8: cannot find package "_/go/src/app/proxy/vendor/github.com/davecgh/go-spew/spew" in any of:
        /usr/local/go/src/_/go/src/app/proxy/vendor/github.com/davecgh/go-spew/spew (from $GOROOT)
        /go/src/_/go/src/app/proxy/vendor/github.com/davecgh/go-spew/spew (from $GOPATH)

I have no idea what I should do with this underscore. I'm not even sure if this is a packaging problem, or if I should file the issue against golang directly, or If I just need to sleep and try reading the documentation and work this out tomorrow.

[justincormack]

You don't want a src/ directory at the top of your repo if you are doing this. That also doesn't fit with the Go requirements, as other people using your repo won't be able to use it easily.

[titpetric]

Sure, src/ would never be commited. In that sense it just behaves as a vendor/, but it actually... works. I need to sleep on it to figure out what the subpackage issue with vendor/ is, ...

[titpetric]

So, I figured out that local imports ("./subpackage") don't work with vendoring. More information is available in the issue upstream. If you're doing something similar and you're coming across this thread, please see this upstream issue for a work-around.