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.

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

Proposal: supporting “symlinks” in GOPATH #15507

Closed
myitcv opened this issue May 2, 2016 · 3 comments
Closed

Proposal: supporting “symlinks” in GOPATH #15507

myitcv opened this issue May 2, 2016 · 3 comments

Comments

@myitcv
Copy link
Member

myitcv commented May 2, 2016

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

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.

@myitcv
Copy link
Member Author

myitcv commented May 2, 2016

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

@ianlancetaylor ianlancetaylor added this to the Proposal milestone May 2, 2016
@robpike
Copy link
Contributor

robpike commented Aug 22, 2016

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants