vendor: go build error when in some dependence

[hilyjiang]

I just try to build my project with GO15VENDOREXPERIMENT support with glide.
But I found there is something wrong when build it.

Code Tree:

# tree 
.
├── main.go
└── vendor
    ├── a
    │   └── a.go
    └── b
        ├── b.go
        └── vendor
            └── a
                └── a.go
# find .
.
./vendor
./vendor/b
./vendor/b/b.go
./vendor/b/vendor
./vendor/b/vendor/a
./vendor/b/vendor/a/a.go
./vendor/a
./vendor/a/a.go
./main.go

vendor/a and vendor/b/vendor/a are same package.

vendor/a/a.go

package a

type T struct {
    Name string
}

func Test() *T {
    return &T{"a"}
}

vendor/b/b.go

package b

import (
    "a"
)

func Test() *a.T {
    return &a.T{"b"}
}

main.go

package main

import (
    "a"
    "b"
    "fmt"
)

func main() {
    var t1, t2 *a.T
    t1 = a.Test()
    t2 = b.Test()
    fmt.Println(t1, t2)
}

When run go build, error occur:

# go build
# c
./main.go:12: cannot use b.Test() (type *"c/vendor/b/vendor/a".T) as type *"c/vendor/a".T in assignment

Is there other goodway to manage those relationships between packages?
Will go build deal vendor/ specially to meet the use?

[ianlancetaylor]

I don't see how the go tool could reasonably know that your two copies of a are the same package. They are different source files in different directories. Go does not require that all package names be unique.

I think that the tool you use to set up this directory structure will need to recognize common packages and consolidate them into a single place. I don't see how else it could work.

Closing this because I don't see that the go tool can do anything here.

[peasoupio]

I don't understand why it is vendor-tools responsibility to handle this scenario and not Go.
Go can/should easily assume and match the common packages from different /vendor folders!

I'm facing the same issue, it is really inconvenient.

Are there any functional blockers preventing the implementation of such feature?

[adg]

Vendor tools manage vendored dependencies. It seems natural that they should handle deduplication of vendored pacakges.

[peasoupio]

After thoughts, I think I got it: the problem is putting dependencies in different /vendor folders and not aggregating them in the one being go build'd ?

So, theoretically, we could but a dependency definition in different packages. Before we call 'go build', /vendor folders of every module should be empty. Then, in the 'main one' (the one being go build'd), we fetch the dependencies of all the packages and putting them into its /vendor folder. At the end, go will find only one occurrence of a package into that folder.

Does that makes sense? Am I missing something?

[adg]

@benjboyer you're missing a lot of discussion about package management in Go. You might want to describe to the go-package-management and golang-dev mailing lists, and take a look at the list archives to see a lot of what you've missed. It's not a simple issue.

[kostya-sh]

@benjboyer the main problem here is that impossible to verify automatically that vendor/a and vendor/b/vendor/a are compatible with each other (e.g. if they were vendored at different times). Even if these packages are APIs compatible there is no guarantee that behavior hasn't changed. So you should resolve possible conflicts manually. Go cannot do it for you.

[yonderblue]

how do you resolve a conflict, even manually, if the package your importing is from another repository outside your control, and is exporting things with references to other standard repos like x tools repo?

[yonderblue]

Question about it here https://groups.google.com/forum/#!topic/golang-nuts/liKQ6gtU4hk