golang/go

Proposal: supporting “symlinks” in GOPATH

myitcv opened this issue · 3 comments

myitcv commented

On the back of #15201 (comment)

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

kostya-sh commented

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.
  • 👍1
myitcv commented

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

robpike commented

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

  • 👍1
  • 😕3