proposal: vendor links - provide communication on impacts of vendor folder for consuming packages

[kardianos]

If a set of packages copy their dependencies locally, then either those packages must either be the end consumer of those packages or other packages which consume them must use a vendor tool to copy the vendor packages under that repo.

There are packages that want to have both end executables and a consumable API packages. Sometimes the API packages are only used by other packages. Forcing those packages to copy packages locally isn’t always desired.

One way to do this is to vendor your own files:

github.com/user/repo/
    cmd/
        exec1/
            main.go
        exec2/
            main.go
        vendor/
            github.com/user/repo/
                pkg1/
                    a.go
                    b.go
    pkg1/
        a.go
        b.go

This would be the same structure regardless if “cmd” and “pkg1” where in the same repository or different repositories.

Answer 1: Use a symbolic links to link the vendor folder package to the library it uses. This can be used on systems that support symbolic links and on projects that combine the cmd and pkg1 into the same repository. As such, the applicability to this is limited.

Answer 2: Have the “go” tool look for a file under the vendor folder. For the purposes of this I will call it “links.txt”. In this file are a list of import paths that should be compiled as if they lived in the vendor folder. This will work on all systems and work regardless of whether or not cmd and pkg1 are in the same repository.

github.com/user/repo/
    cmd/
        exec1/
            main.go
        exec2/
            main.go
        vendor/
            links.txt
    pkg1/
        a.go
        b.go

$ cat links.txt
github.com/user/repo/…  (specify each package but allow … path matching)
or
github.com/user/repo      (only need to specify roots)
or
github.com/user/repo/pk1  (must specify each package)

Answer 3: The folders “cmd” and “pkg1” should be separate, and if you want reproducible builds by copying vendor dependencies into the project tree, then copying “pkg1” under the “cmd” vendor folder is the correct solution. A project where “cmd”, “pkg1”, and “vendor” are all siblings is incorrect (likely to break normal builds, assuming “pkg1” is designed for external consumption).

---

I understand that people use the vendor folder in different ways and have different build environments, but It would be nice to have a blog post or other "official" communication on project structure with the vendor folder.

Answer 2 looks interesting to me. I don't know if it is interesting to other people as well.

[myitcv]

@kardianos answer 2 (or something very close to it) is exactly the subject of what I was proposing here. Indeed I'm pulling together a proposal as I type... might be worth comparing notes offline?

[gopherbot]

CL https://golang.org/cl/23153 mentions this issue.

[kardianos]

I don't think this is the correct solution. Closing.