Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

vendor: go build error when in some dependence #12432

Closed
hilyjiang opened this issue Sep 1, 2015 · 8 comments
Closed

vendor: go build error when in some dependence #12432

hilyjiang opened this issue Sep 1, 2015 · 8 comments
Labels
FrozenDueToAge

Comments

@hilyjiang
Copy link

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?
@hilyjiang hilyjiang reopened this Sep 1, 2015
@ianlancetaylor
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

adg commented Sep 9, 2015

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

@peasoupio
Copy link

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
Copy link
Contributor

adg commented Sep 9, 2015

@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
Copy link
Contributor

@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
Copy link

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
Copy link

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

@ecordell ecordell mentioned this issue Jan 26, 2017
Merged
This was referenced Feb 23, 2017
Closed
Closed
Closed
@golang golang locked and limited conversation to collaborators Feb 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@yonderblue @hilyjiang @ianlancetaylor @kostya-sh @adg @gopherbot