Go: Proposal: supporting “symlinks” in GOPATH

Created on 2 May 2016 · 3Comments · Source: golang/go

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_

FrozenDueToAge Proposal

Source

myitcv

👍2

All 3 comments

A few comments/questions:

Term "repository" is not defined. What if the source code in GOPATH is not coming from a VSC or coming from Subversion that supports checking out a directory?
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.
As far as I can tell this proposal doesn't solve "library and program in the same repository" problem.

kostya-sh on 2 May 2016

👍1

@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.

myitcv on 2 May 2016

Symlinks are too problematic. It seems unwise to allow them.