-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
cmd/go: panic in test with augmented GOPATH and symlink to 'self' #15201
Comments
I don't think the go tool is going to support symlinks within GOPATH, but clearly it should fail in a nicer way. |
@ianlancetaylor thanks, I always forget Windows in this equation which is I guess why, generally speaking, symlinks are not supported? |
All recent Windows versions do support symlinks. And Go standard library does support symlinks on Windows (when available). Alex |
If, as it sounds like is the case, there isn't 100% support for symlinks across first-class Go platforms, has there been any thought given to a This need only be something known to Purely a gut feeling based on vendoring discussions to date, but if there were "symlink"-like support within |
@myitcv, interesting thought. |
@bradfitz happy to kick start a proposal (or similar, I'll read up on the proposal process) if you think it's worth it? |
CL https://golang.org/cl/31665 mentions this issue. |
Thanks @rsc |
This issue follows on from the golang-dev thread about a vendoring problem, specifically my response. In the repro repo linked to below, I'm trying to make the
cmd/a
binarygo get
-able (withvendor
-ed dependencies, per this definition) whilst allowing the library developer to "vendor" dependencies via$GOPATH
augmentation as part of his/her development/build workflow (good practice).Full repro details here (
README
gives details): https://github.com/myitcv/go-vendoringThe directory structure of the repro repo is as follows:
As the
README
shows, the problem comes when you augmentGOPATH
to include_vendor
(the tree under_vendor
effectively has a reference to self as shown above) and then re-rungo test ./...
$GOPATH
at this point looks something like this:As you can see from the directory structure above (which is a
tree -d
of/home/myitcv/gostuff/src/github.com/myitcv/go-vendoring
), there is a symlink in the first (higher precedence)$GOPATH
entry to a directory outside of the first entry, specifically the directory from which we are runninggo test ./...
Per the
README
, I expected a successful second run ofgo test ./...
but instead got the following panic:Am I breaking a rule by symlinking in this way?
I hope not, because it feels like a nice clean solution to the
go get
problem I mention in my response to the aforementioned thread.The text was updated successfully, but these errors were encountered: