On the back of https://github.com/golang/go/issues/15201#issuecomment-208602586
We propose a means by which cmd/go and friends leverage regular files to simulate symlink-like behaviour within a repository during GOPATH package resolution in a platform agnostic way
https://docs.google.com/document/d/1n5y3mZPs_4PjI80a0vZEaHLe7r9PeiiE9xsIrQFT8Is/edit
Thanks to @kardianos for sharing his initial thoughts offline
_The name "symlink" is bound to prompt a good discussion in and of itself: I would hope we can discuss names/naming separately from the crux of the proposal_
A few comments/questions:
@kostya-sh
Term "repository" is not defined
The first footnote gives details - it's the same definition as assumed here. But I agree the question still remains whether "repository" is formally defined somewhere?
What if the source code in GOPATH is not coming from a VSC or coming from Subversion that supports checking out a directory?
Open question - I admit the only consideration thus far has been for code that is part of a "repository". I've added an "open questions" section at the bottom referencing this question.
if a repository contains multiple public binaries then it is not necessary to copy dependencies multiple times. vendored dependencies can be placed under cmd/vendor
Indeed that's one approach to share vendored code between binaries. But the "symlink" approach helps to facilitate the approach of sharing that "vendor" with the library code (see next point)
As far as I can tell this proposal doesn't solve "library and program in the same repository" problem.
This proposal by itself does not, no. But the repository linked to from the "Motivating example" section outlines how that problem can be solved by using a combination of "symlinks" and GOPATH augmentation.
Symlinks are too problematic. It seems unwise to allow them.