cmd/go: go get fails when repository ends with .go
#32483
Comments
bcmills
changed the title
go get fails when repository ends with .go unless it has a trailing slashgo get fails when repository ends with .go unless it has a trailing slash
bcmills
added
modules
NeedsInvestigation
|
Paths ending in CC @jayconrod |
|
Change https://golang.org/cl/180923 mentions this issue: |
|
@dmitshur, I'm still quite new to golang project workflow, so, thanks for the reminder, and please guide me through this second CL. My fix in above CL is basically trying load patterns ended with |
|
Thanks @letientai299. You should discuss the approach you've considered with @bcmills and @jayconrod here, since they're owners of
I have a potential concern about it, in that it introduces unpredictable behavior. The same command invocation may act differently depending on whether or not a .go file exists and can be accessed without errors. I'm not sure of a better solution, I just wanted to point out the potential concern. |
|
Note that the same command also fails in GOPATH mode, at least as far back as 1.11.10: Given the lack of other reports of this issue, perhaps (Or are there substantially more examples of this in the wild?) |
|
@bcmills I mean that the issue mentions others running into a similar issue, though we also commented on that issue. Btw thanks @letientai299 for looking at the possible fix! |
Previous implementation also have that issue. The code check if there's any pattern ends with |
|
It looks like this behavior has worsened in Go 1.13, now it is not possible at all to |
wallyqs
changed the title
go get fails when repository ends with .go unless it has a trailing slashgo get fails when repository ends with .go
|
Only variation that seems to work is when disabling go modules and adding a trailing slash to GO111MODULE=off go get github.com/nats-io/nats.go
stat github.com/nats-io/nats.go: no such file or directory
GO111MODULE=off go get github.com/nats-io/nats.go/
# No `trailing slash` error |
jayconrod
added
NeedsFix
|
Change https://golang.org/cl/194600 mentions this issue: |
|
CL 194600 should fix the regression in 1.13. I'd like to backport that for 1.13.1 if possible.
When we do the work needed to update go.mod, we weren't stripping trailing slashes from arguments with versions. So If we do strip the trailing slashes, then the second |
|
Note that the I think I'm ok with a minimal change to restore compatibility with commands that happened to work in 1.12, but I can't justify sinking a lot of time into ongoing support for these names that never really worked to begin with. |
|
@bcmills For ecosystems like NATS that have many client implementations it has become pretty common to name the client repo .. This is not just a NATS thing. This is a silly problem that the Go team should resolve. |
|
For instance - https://github.com/miscreant |
'go get' accepts arguments of the form path@version, and it passes them through search.CleanPatterns before querying proxies. With this change, CleanPatterns preserves text after '@' and will strip trailing slashes from the patn. Previously, we did not strip trailing slashes when a version was present, which caused proxy base URL validation to fail. Module paths that end with ".go" (for example, github.com/nats-io/nats.go) use trailing slashes to prevent 'go build' and other commands from interpreting packages as source file names, so this caused unnecessary problems for them. Updates #32483 Change-Id: Id3730c52089e52f1cac446617c20132a3021a808 Reviewed-on: https://go-review.googlesource.com/c/go/+/194600 Run-TryBot: Jay Conrod <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]>
|
@gopherbot please backport to 1.13, this was a regression |
|
Backport issue(s) opened: #34243 (for 1.13). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
|
Thanks, much appreciated. |
|
Thanks @jayconrod @bcmills just tried it building Go from master and it works great 🙌 |
|
1.13.1 is out, but the problem still exists: How to add NATS client to a project? |
|
@halega, Go 1.13.1 was a security release. Such releases contain only the relevant security fix and no other changes, in order to make them safer to update to. All other changes will be a part of the next minor release, Go 1.13.2, which will happen soon (beginning of October). |
|
Change https://golang.org/cl/198459 mentions this issue: |
|
Change https://golang.org/cl/198957 mentions this issue: |
|
Was expecting this to be in 1.13.2 but it was not. Any estimations or timeframe to have this released? |
|
1.13.2 ended up being a security release, so everything not security-related got bumped to 1.13.3. |
|
We just figured out that the fix was not in there. Do you folks have an eta? |
|
Should be out soon enough. Feel free to subscribe to #34970. |
|
Thanks! |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
When trying to fetch the latest version or a tag of the NATS Go client as follows, it fails with a
no such file or directoryerror.One workaround for this when using Go 1.12 is to append an extra slash at the end of the repository name and then add the explicit version as follows:
GO111MODULE=on go get github.com/nats-io/nats.go/@latest ... # Explicit tag version GO111MODULE=on go get github.com/nats-io/nats.go/@v1.8.0 go: finding github.com/nats-io/nats.go v1.8.0 go: downloading github.com/nats-io/nats.go v1.8.0 go: extracting github.com/nats-io/nats.go v1.8.0What did you expect to see?
I expected
go getto download the library as follows:Or when not specifying a version either, expected for it to download the latest one:
What did you see instead?
Also when not specifying any version always fail, regardless of trailing slash or not:
The text was updated successfully, but these errors were encountered: