cmd/go: `go get` fails when repository ends with `.go` #32483

wallyqs · 2019-06-07T19:27:37Z

What version of Go are you using (`go version`)?

$ go version
go version go1.12 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

go env Output

$ go env
GOARCH="amd64"

GOBIN=""

GOCACHE="/Users/himitsu/Library/Caches/go-build"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH="/Users/himitsu/repos/lkjh-dev"

GOPROXY=""

GORACE=""

GOROOT="/usr/local/Cellar/go/1.12/libexec"

GOTMPDIR=""

GOTOOLDIR="/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64"

GCCGO="gccgo"

CC="clang"

CXX="clang++"

CGO_ENABLED="1"

GOMOD=""

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/xl/vzfvbyrs29s3t2mmh15ygmv00000gn/T/go-build506667951=/tmp/go-build -gno-record-gcc-switches -fno-common"

What 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 directory error.

GO111MODULE=on go get github.com/nats-io/nats.go@latest
stat github.com/nats-io/nats.go: no such file or directory

GO111MODULE=on go get github.com/nats-io/nats.go@v1.8.1
stat github.com/nats-io/nats.go: no such file or directory

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

What did you expect to see?

I expected go get to download the library as follows:

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

Or when not specifying a version either, expected for it to download the latest one:

GO111MODULE=on go get github.com/nats-io/nats.go
go: finding github.com/nats-io/nats.go v1.8.1
go: downloading github.com/nats-io/nats.go v1.8.1
go: extracting github.com/nats-io/nats.go v1.8.1

What did you see instead?

GO111MODULE=on go get github.com/nats-io/nats.go@v1.8.0
stat github.com/nats-io/nats.go: no such file or directory

Also when not specifying any version always fail, regardless of trailing slash or not:

GO111MODULE=on go get github.com/nats-io/nats.go/
stat github.com/nats-io/nats.go: no such file or directory

GO111MODULE=on go get github.com/nats-io/nats.go
stat github.com/nats-io/nats.go: no such file or directory

The text was updated successfully, but these errors were encountered:

bcmills · 2019-06-07T21:17:13Z

Paths ending in .go usually refer to source files rather than package or module paths; presumably that is the problem here.

CC @jayconrod

gopherbot · 2019-06-10T19:09:10Z

Change https://golang.org/cl/180923 mentions this issue: cmd/goget: support package ended with '.go'

letientai299 · 2019-06-10T19:22:11Z

@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 .go as go files, and if it fails, fall back to loading the patterns as packages.

dmitshur · 2019-06-10T19:27:21Z

Thanks @letientai299. You should discuss the approach you've considered with @bcmills and @jayconrod here, since they're owners of cmd/go behavior, and see what they think.

trying load patterns ended with .go as go files, and if it fails, fall back to loading the patterns as packages.

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.

bcmills · 2019-06-10T20:40:11Z

Note that the same command also fails in GOPATH mode, at least as far back as 1.11.10:

$ GO111MODULE=off go1.12.5 get github.com/nats-io/nats.go
stat github.com/nats-io/nats.go: no such file or directory

$ GO111MODULE=off go1.11.10 get github.com/nats-io/nats.go
stat github.com/nats-io/nats.go: no such file or directory

Given the lack of other reports of this issue, perhaps nats-go should just pick a less ambiguous name for their module‽

(Or are there substantially more examples of this in the wild?)

wallyqs · 2019-06-10T20:58:30Z

@bcmills yes you also have to add trailing slash if not using Go modules. From a similar past issue that is open it seems that this may have been introduced around Go 1.11, still ok in Go 1.10: #27096

bcmills · 2019-06-10T21:00:12Z

@wallyqs, note that the concrete example of such a package in #27096 is also nats-io/nats.go.

wallyqs · 2019-06-10T21:39:12Z

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

letientai299 · 2019-07-03T04:46:35Z

@dmitshur

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.

Previous implementation also have that issue. The code check if there's any pattern ends with .go and treat all of them as go files.

wallyqs · 2019-09-09T15:58:56Z

It looks like this behavior has worsened in Go 1.13, now it is not possible at all to go get the nats module repository:

# --- Go 1.13
GO111MODULE=on go get github.com/nats-io/nats.go/@v1.8.0
go: finding github.com v1.8.0
go: finding github.com/nats-io v1.8.0
go get github.com/nats-io/nats.go/@v1.8.0: malformed module path "github.com/nats-io/nats.go/": trailing slash

GO111MODULE=on go get github.com/nats-io/nats.go/@latest
go get github.com/nats-io/nats.go/@latest: malformed module path "github.com/nats-io/nats.go/": trailing slash

GO111MODULE=on /usr/local/go/bin/go get github.com/nats-io/nats.go
stat github.com/nats-io/nats.go: no such file or directory

GO111MODULE=on /usr/local/go/bin/go get github.com/nats-io/nats.go/
stat github.com/nats-io/nats.go: no such file or directory

GO111MODULE=on go get github.com/nats-io/nats.go@latest
stat github.com/nats-io/nats.go: no such file or directory

GO111MODULE=on go get github.com/nats-io/nats.go@v1.8.0
go: finding github.com v1.8.0
go: finding github.com/nats-io v1.8.0
stat github.com/nats-io/nats.go: no such file or directory

derekcollison · 2019-09-09T17:30:09Z

@bcmills Please keep us posted on this. Seems pretty bad behavior that has totally broke the NATS.io ecosystem. NATS has been with Go since 0.52 IIRC.

/cc @bradfitz @Sajmani

wallyqs · 2019-09-09T17:47:13Z

Only variation that seems to work is when disabling go modules and adding a trailing slash to go get:

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

gopherbot · 2019-09-10T20:43:51Z

Change https://golang.org/cl/194600 mentions this issue: cmd/go: strip trailing slash from versioned arguments

jayconrod · 2019-09-10T20:55:22Z

CL 194600 should fix the regression in 1.13. I'd like to backport that for 1.13.1 if possible.

go get operates in two phases: it updates go.mod, then runs go build on the arguments (kind of). Both phases are having problems.

When we do the work needed to update go.mod, we weren't stripping trailing slashes from arguments with versions. So go get -d github.com/nats-io/nats.go/@latest would fail when we went to validate the proxy base URL, since trailing slashes aren't allowed in a module path. It works without the trailing slash though (go get -d github.com/nats-io/nats.go@latest succeeds).

If we do strip the trailing slashes, then the second go build phase fails because it treats arguments ending with .go as files, unlike the rest of go get. So CL 194600 will strip trailing slashes but preserve them for this phase.

bcmills · 2019-09-10T21:07:33Z

Note that the nats.go maintainers in particular knew that this repo name was a problem literally four days after renaming the repository and didn't roll back at that point.
(Compare the dates on #27096 (comment) and nats-io/nats.go@4c154eb.)

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.

derekcollison · 2019-09-10T21:14:13Z

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

derekcollison · 2019-09-10T21:17:55Z

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 <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>

jayconrod · 2019-09-11T20:21:21Z

@gopherbot please backport to 1.13, this was a regression

gopherbot · 2019-09-11T20:21:27Z

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.

derekcollison · 2019-09-11T20:35:08Z

Thanks, much appreciated.

wallyqs · 2019-09-11T23:14:05Z

Thanks @jayconrod @bcmills just tried it building Go from master and it works great 🙌
Looking forward to the 1.13.1 release!

halega · 2019-09-26T13:21:10Z

1.13.1 is out, but the problem still exists:

$ go version
go version go1.13.1 windows/amd64

$ go get github.com/nats-io/nats.go/@latest
go get github.com/nats-io/nats.go/@latest: malformed module path "github.com/nats-io/nats.go/": trailing slash

$ go get github.com/nats-io/nats.go@latest
CreateFile github.com/nats-io/nats.go: The system cannot find the path specified.

How to add NATS client to a project?

dmitshur · 2019-09-26T13:30:06Z

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

gopherbot · 2019-10-04T10:16:19Z

Change https://golang.org/cl/198459 mentions this issue: cmd/go: fix listing of ambiguous paths

gopherbot · 2019-10-04T14:02:18Z

Change https://golang.org/cl/198957 mentions this issue: cmd/go: fix listing of ambiguous paths

derekcollison · 2019-10-17T21:33:03Z

Was expecting this to be in 1.13.2 but it was not. Any estimations or timeframe to have this released?

bcmills · 2019-10-17T21:42:19Z

1.13.2 ended up being a security release, so everything not security-related got bumped to 1.13.3.

derekcollison · 2019-10-17T21:48:24Z

We just figured out that the fix was not in there. Do you folks have an eta?

agnivade · 2019-10-18T03:39:43Z

Should be out soon enough. Feel free to subscribe to #34970.

derekcollison · 2019-10-18T10:23:16Z

Thanks!

wallyqs mentioned this issue Jun 7, 2019

Cannot go get client nats-io/nats.go#478

Closed

bcmills changed the title ~~cmd/go/: go get fails when repository ends with .go unless it has a trailing slash~~ cmd/go: go get fails when repository ends with .go unless it has a trailing slash Jun 7, 2019

bcmills added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 7, 2019

bcmills added this to the Go1.14 milestone Jun 7, 2019

bcmills removed the modules label Jun 10, 2019

wallyqs mentioned this issue Aug 2, 2019

MacOS (Mojave) - Github pull of stan.go repo shows "No Such file or directory" (but exists) nats-io/stan.go#256

Closed

kozlovic mentioned this issue Aug 12, 2019

Update the "go get" instruction to avoid error report [ci skip] nats-io/stan.go#261

Merged

dmitshur added the GoCommand cmd/go label Aug 25, 2019

wallyqs changed the title ~~cmd/go: go get fails when repository ends with .go unless it has a trailing slash~~ cmd/go: go get fails when repository ends with .go Sep 9, 2019

kozlovic mentioned this issue Sep 10, 2019

Tests still import nats-streaming-server and break go mod nats-io/stan.go#280

Closed

bcmills assigned jayconrod Sep 10, 2019

jayconrod added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 10, 2019

gopherbot mentioned this issue Sep 11, 2019

cmd/go: go get fails when repository ends with .go [1.13 backport] #34243

Closed

jayconrod removed their assignment Sep 12, 2019

bcmills mentioned this issue Sep 12, 2019

x/tools/go/analysis/internal/checker: TestApplyFixes broken at head #34265

Closed

derekcollison mentioned this issue Sep 17, 2019

go get fail on Go 1.13 nats-io/nats.go#522

Closed

bcmills mentioned this issue Oct 2, 2019

cmd/go: loading dependencies with go test -i does not correctly handle *.go import paths #34653

Closed

Helcaraxan mentioned this issue Oct 4, 2019

cmd/go: fix listing of ambiguous paths #34663

Closed

gopherbot closed this as completed in 8c74bfb Oct 4, 2019

Helcaraxan mentioned this issue Oct 4, 2019

cmd/go: loading dependencies with go test -i does not correctly handle *.go import paths [1.13 backport] #34694

Closed

ChrisHines mentioned this issue Jan 6, 2020

Module Path Error - "github.com/nats-io/nats.go" go-kit/kit#940

Closed

jayconrod mentioned this issue Apr 16, 2020

cmd/go: do not lookup *.go domains #38478

Closed

golang locked and limited conversation to collaborators Oct 17, 2020

gopherbot added the FrozenDueToAge label Oct 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: `go get` fails when repository ends with `.go` #32483

cmd/go: `go get` fails when repository ends with `.go` #32483

wallyqs commented Jun 7, 2019 •

edited

bcmills commented Jun 7, 2019

gopherbot commented Jun 10, 2019

letientai299 commented Jun 10, 2019 •

edited by dmitshur

dmitshur commented Jun 10, 2019 •

edited

bcmills commented Jun 10, 2019

wallyqs commented Jun 10, 2019

bcmills commented Jun 10, 2019

wallyqs commented Jun 10, 2019

letientai299 commented Jul 3, 2019

wallyqs commented Sep 9, 2019 •

edited

derekcollison commented Sep 9, 2019

wallyqs commented Sep 9, 2019

gopherbot commented Sep 10, 2019

jayconrod commented Sep 10, 2019

bcmills commented Sep 10, 2019

derekcollison commented Sep 10, 2019

derekcollison commented Sep 10, 2019

jayconrod commented Sep 11, 2019

gopherbot commented Sep 11, 2019

derekcollison commented Sep 11, 2019

wallyqs commented Sep 11, 2019

halega commented Sep 26, 2019 •

edited

dmitshur commented Sep 26, 2019

gopherbot commented Oct 4, 2019

gopherbot commented Oct 4, 2019

derekcollison commented Oct 17, 2019

bcmills commented Oct 17, 2019

derekcollison commented Oct 17, 2019

agnivade commented Oct 18, 2019

derekcollison commented Oct 18, 2019

cmd/go: go get fails when repository ends with .go #32483

cmd/go: go get fails when repository ends with .go #32483

Comments

wallyqs commented Jun 7, 2019 • edited

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

bcmills commented Jun 7, 2019

gopherbot commented Jun 10, 2019

letientai299 commented Jun 10, 2019 • edited by dmitshur

dmitshur commented Jun 10, 2019 • edited

bcmills commented Jun 10, 2019

wallyqs commented Jun 10, 2019

bcmills commented Jun 10, 2019

wallyqs commented Jun 10, 2019

letientai299 commented Jul 3, 2019

wallyqs commented Sep 9, 2019 • edited

derekcollison commented Sep 9, 2019

wallyqs commented Sep 9, 2019

gopherbot commented Sep 10, 2019

jayconrod commented Sep 10, 2019

bcmills commented Sep 10, 2019

derekcollison commented Sep 10, 2019

derekcollison commented Sep 10, 2019

jayconrod commented Sep 11, 2019

gopherbot commented Sep 11, 2019

derekcollison commented Sep 11, 2019

wallyqs commented Sep 11, 2019

halega commented Sep 26, 2019 • edited

dmitshur commented Sep 26, 2019

gopherbot commented Oct 4, 2019

gopherbot commented Oct 4, 2019

derekcollison commented Oct 17, 2019

bcmills commented Oct 17, 2019

derekcollison commented Oct 17, 2019

agnivade commented Oct 18, 2019

derekcollison commented Oct 18, 2019

cmd/go: `go get` fails when repository ends with `.go` #32483

cmd/go: `go get` fails when repository ends with `.go` #32483

wallyqs commented Jun 7, 2019 •

edited

What version of Go are you using (`go version`)?

What operating system and processor architecture are you using (`go env`)?

letientai299 commented Jun 10, 2019 •

edited by dmitshur

dmitshur commented Jun 10, 2019 •

edited

wallyqs commented Sep 9, 2019 •

edited

halega commented Sep 26, 2019 •

edited