Go: cmd/go: needs a better error than "missing dot in first path element" when GOROOT is set incorrectly

[damozhiying]

what's wrong about the error
build command-line-arguments: cannot load golang_org/x/crypto/chacha20poly1305: malformed module path "golang_org/x/crypto/chacha20poly1305": missing dot in first path element

[damozhiying]

[antong]

I typed in the code in the screenshot and ran the code without any error with the same go version you have. @damozhiying , could you include all the information that is in the issue template, including go env output. Also, it would be much easier if you would post as text and not images.

[katcipis]

Im getting a similar behaviour, the code is not open source and I haven't isolated the problem yet, but the same code that was working 5 minutes ago with Go 1.12.9 now gives this error with 1.13. Running go mod vendor results in:

github.com/prv/store imports
    cloud.google.com/go/datastore imports
    google.golang.org/api/option imports
    golang.org/x/oauth2/google imports
    golang.org/x/oauth2/jws imports
    crypto: malformed module path "crypto": missing dot in first path element
github.com/prv/store imports
    cloud.google.com/go/datastore imports
    google.golang.org/api/option imports
    golang.org/x/oauth2/google imports
    golang.org/x/oauth2/jws imports
    crypto/sha256: malformed module path "crypto/sha256": missing dot in first path element
github.com/prv/store imports
    cloud.google.com/go/datastore imports
    google.golang.org/api/transport/grpc imports
    go.opencensus.io/plugin/ocgrpc imports
    go.opencensus.io/tag imports
    runtime/pprof: malformed module path "runtime/pprof": missing dot in first path element
github.com/prv/store imports
    cloud.google.com/go/datastore imports
    google.golang.org/grpc imports
    golang.org/x/net/http2 imports
    golang.org/x/net/idna imports
    golang.org/x/text/unicode/bidi imports
    container/list: malformed module path "container/list": missing dot in first path element

go test ./... and go get ./...:

build github.com/prv/cmd/prv: cannot load bufio: malformed module path "bufio": missing dot in first path element

OS:

uname -a     
Darwin macbook 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64

Go:

go version
go version go1.13 darwin/amd64

Got suspicious of a recent change that I made in my environment, which is setting GOPATH. unset GOPATH and now everything works. The odd thing is that the project is outside the GOPATH and has go.mod, everything seems to be on module mode, but if there is a GOPATH set in my env the go commands fails with these odd error messages

[bcmills]

@katcipis, @damozhiying: as @antong notes, we need concrete steps to reproduce the problem.

Please fill out the complete issue template, and provide specific commands — as text that we can easily copy and paste — that we can run to reproduce the problem.

[maniLonkar]

Use https://ahmadawais.com/install-go-lang-on-macos-with-homebrew/ to setup env

[bcmills]

@maniLonkar, brew install go is not a command supported by the Go team. If you are observing this issue, please provide steps to reproduce it either starting from source or using the _official_ distribution from https://golang.org/dl.

[deavid]

Just ran on the same problem while doing the Go tour in spanish:
https://gotour-es.appspot.com/#45

build command-line-arguments: cannot load tour/wc: malformed module path "tour/wc": missing dot in first path element

The english version seems corrected:
https://tour.golang.org/moretypes/23

Something has changed recently

[amossc]

I hit this error when following the instructions to install gopls:

GO111MODULE=on go get golang.org/x/tools/gopls@latest
go: finding golang.org/x/tools latest
go: finding golang.org/x/tools/gopls v0.1.5
go: downloading golang.org/x/tools v0.0.0-20190916020655-1ccc110ba9df
go: downloading golang.org/x/tools/gopls v0.1.5
go: extracting golang.org/x/tools v0.0.0-20190916020655-1ccc110ba9df
go: extracting golang.org/x/tools/gopls v0.1.5
go: downloading golang.org/x/tools v0.0.0-20190911225940-c7d52e45e2f2
go: extracting golang.org/x/tools v0.0.0-20190911225940-c7d52e45e2f2
go: downloading golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7
go: downloading golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: extracting golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7
go: extracting golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: finding golang.org/x/tools v0.0.0-20190911225940-c7d52e45e2f2
build golang.org/x/tools/gopls: cannot load bufio: malformed module path "bufio": missing dot in first path element

$ go version
go version go1.13 darwin/amd64

Instructions taken from: https://github.com/golang/go/wiki/gopls

[bcmills]

@amossc, please include the output of go env.

Are you using the official Go distribution, or something installed via brew?

[HuanGong]

same issue here, Nightmare...

[InfernoEmperor]

same issue here, Nightmare...

[me440378]

May I ask how to fix this problem?

[me440378]

I found that if you set the GOROOT right,the problem would be solved.

[ALTree]

@bcmills In #34245 (dup of this one) @maniLonkar reported that Installing Go from brew appears to fix the issue, so I'm guessing that this only hits people that installed Go from the official distribution. In that issue, the output of go env was also pasted.

@HuanGong @InfernoEmperor just writing that you have the same issue doesn't help much. Can you please 1) write here how you installed Go 2) paste here the output of Go env 3) provide steps to reproduce the issue (i.e. a sequence of terminal commands that trigger the error). Thanks.

[wanghaolonggit]

怎么解决的？

[me440378]

怎么解决的？

我把GOROOT的环境变量重新设置为了GO的安装路径就解决了,如果你的GOROOT环境变量的内容不是GO的安装路径可以试试

[mjyuser]

when I use /usr/local/go/bin/go1.13 env -w GOPROXY=https://goproxy.cn,direct && /usr/local/go/bin/go1.13 env -w GOPRIVATE=git.kuainiujinke.com && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 /usr/local/go/bin/go1.13 build -o feature --tags release main.go in jenkins, occur this error, the machine conf version is Linux version 4.9.87-linuxkit-aufs (root@95fa5ec30613) (gcc version 6.4.0 (Alpine 6.4.0) ) #1 SMP Wed Mar 14 15:12:16 UTC 2018, go version go1.13 linux/amd64

[bcmills]

@me440378, @wanghaolonggit: it is usually best to leave the GOROOT environment variable unset. It has not been necessary for a long time — perhaps since Go 1.0?

(See https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really.)

[bcmills]

@mjyuser, please provide steps to reproduce the problem without using Jenkins. (Given the information that @me440378 provided, it probably has something to do with the process's environment.)

[me440378]

@mjyuser, please provide steps to reproduce the problem without using Jenkins. (Given the information that @me440378 provided, it probably has something to do with the process's environment.)

As you said, it may not be related to GOROOT? I started by making a soft link file of go executable file into the bin directory of my home directory, set the home directory to GOROOT, and set GOBIN to GOROOT/bin. After that, I got into trouble. This problem is solved when I reset GOROOT to the GO installation directory.

[doug4j]

I was getting missing dot in first path element error but then discovered the module name in my go.mod when it was module github.com/doug4j/templ (note: the user name should be doug4j NOT doug4 I got the following error on go mod tidy:

github.com/doug4/templ/go/cmd/templ imports
    github.com/doug4j/templ/go/cmd/templ/cmd: module github.com/doug4j/templ@latest (v0.0.0-20180620223934-65a7663df59d) found, but does not contain package github.com/doug4j/templ/go/cmd/templ/cmd
github.com/doug4/templ/go/templcore/tealegxlsx imports
    github.com/doug4j/templ/go/templcore imports
    simpledateformat: malformed module path "simpledateformat": missing dot in first path element
github.com/doug4/templ/go/templcore/tealegxlsx imports
    github.com/doug4j/templ/go/templcore imports
    templ/go/logr: malformed module path "templ/go/logr": missing dot in first path element
github.com/doug4/templ/go/templcore/tealegxlsx imports
    github.com/doug4j/templ/go/templcore imports
    templ/go/templapi: malformed module path "templ/go/templapi": missing dot in first path element
github.com/doug4/templ/go/templcore/tealegxlsx imports
    github.com/doug4j/templ/go/templcore imports
    templ/go/util: malformed module path "templ/go/util": missing dot in first path element

When I put the module name correctly as module github.com/doug4j/templ (with the "j" at the end) all was well.

I didn't have to adjust GOROOT or GOPATH at all.

Just wanted to note this in case it helps someone else.

[mjyuser]

@bcmills my local docker have go1.12.9 and go1.13, when i run build, the error reporting
/usr/local/go/bin/go1.13 env -w GOPRIVATE=git.kuainiujinke.com && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 /usr/local/go/bin/go1.13 build -o feature --tags release main.go

i tried @me440378 method, but no success

[mjyuser]

may be the reason for the image, i built a image of centos 7.6 and installed both versions 1.12 and 1.13, the use of image will be abnormal, but when i build an official go:latest image, the process is successful

[amossc]

@bcmills here is the output of go env. I'm using go installed via brew install go:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/amos/Library/Caches/go-build"
GOENV="/Users/amos/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY="github.com/SafetyCulture"
GONOSUMDB="github.com/SafetyCulture"
GOOS="darwin"
GOPATH="/Users/amos/casesafe/go"
GOPRIVATE="github.com/SafetyCulture"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
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/wh/s26xk7_1265f4qgkrmkghgsh0000gn/T/go-build836927503=/tmp/go-build -gno-record-gcc-switches -fno-common"

[bcmills]

@amossc, please try removing the brew-installed Go toolchain and installing from the official distribution (https://golang.org/dl) instead.

The GOROOT="/usr/local/Cellar/go/1.13/libexec" line in your go env output looks suspicious as well — did you set that explicitly?

[bcmills]

@doug4j, if your module path was mismatched, most likely the go command was fetching and downloading the latest version published at github.com/doug4j/templ. Is it possible that the latest tagged version (or latest published commit, if no semver tags exist) used import paths missing the github.com/doug4j prefix?

[doug4j]

@bcmills Yes that precisely what happened. Thanks for the clear explanation. The problem is resolved for me by fixing the error in my module name to "github.com/doug4j/templ" (with the j in doug4j). I was posting my experience in case it helped others. I'm good. 👍

[xroba]

Hello I had the same issue today on v1.13.1
cannot load bufio: malformed module path "bufio": missing dot in first path element

I solved it by :

1. I check my $GOROOT env => echo $GOROOT via the terminal and it was empty
2. I set my $GOROOT then to my install dir of go => export GOROOT=/usr/local/go

All is now working :-)

[bcmills]

This issue has gotten a lot more traffic than I would have expected.

Folks who have run into this: what led you to set GOROOT in the first place? If there is some documentation instructing you to do so, we should probably fix that documentation.

(See also: https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really.)

[gustavolopess]

I am using gvm with go version go1.13 darwin/amd64 and facing same problem. I've already set GOROOT to empty, change it to be equal to GOPATH and still doesn't work, I think there's not to do with GOROOT.

[chaitanya-apty]

Dont know the root cause But after downgrading (and installing) go 1.12 ,problem is not present for me

[bcmills]

@chaitanya-apty, the difference there is likely due to the change to GO111MODULE=auto in 1.13.

The underlying problem is likely due to the erroneous GOROOT value, so that is what we need to address: we need a better diagnostic for invalid GOROOT settings, and we need to figure out how so many people are ending up with a bad GOROOT to begin with.

[bcmills]

@gustavolopess, setting GOROOT equal to GOPATH is definitely not going to help. GOROOT needs to point to the root of the Go source tree.

In your case, is it possible that gvm build a Go toolchain and then subsequently moved it to a different directory? That would result in an invalid GOROOT being embedded in the binary itself.

[bcmills]

@xroba, how had you installed the go toolchain on your system?

[phantomSuying]

anyone deal with it?

[bcmills]

Nobody seems to be providing information about how the invalid GOROOT was set, but given the seeming diversity of these error reports it seems clear to me that we need a better diagnostic no matter how it happens.

[bradwilzon]

@bcmills how is GOROOT supposed to look? I'm having this problem as well using Goland 2019.2.3 (2019-10-01 build) and/usr/local/Cellar/go/1.13/libexec is the default (and only) option my IDE has for setting GOROOT.

My company machine is managed by some super long running script that we run every once in a while, and that's likely how I upgraded to 1.13. It wouldn't surprise me at all if the script is using brew to install Go. Do you believe installation this way could cause this problem?

[rsc]

Duplicate of #34769.

[Mantic]

What about windows users? I'm using Windows 10 and git's mingw64 terminal. Everything was working until I rebooted my computer. I have no GOROOT set... If I should set it, what do I set it to?

[bcmills]

@Mantic, you want go env GOROOT to be the directory above the \bin\ component in the path reported by where go.

[ianlancetaylor]

@Mantic Note that a closed issue is not the best place to ask questions. See https://golang.org/wiki/Questions. Thanks.

[AmitShaul]

I'm trying to install "google/api/annotations.proto" and keep getting:
go get google/api/annotations.proto: malformed module path "google/api/annotations.proto": missing dot in first path element
I installed go in the recommended way.

when I echo $GOROOT I get an empty result though in my "go env" variables it's set to "/usr/local/go":

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/amit/Library/Caches/go-build"
GOENV="/Users/amit/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/amit/workspace/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
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"

[lobo-a]

go version go1.13.1 linux/amd64

Environment:
GOROOT=/home/yx/server/go
GOBIN=/home/yx/server/go/bin
GOPATH=/home/yx/goproj
Directory: /home/yx/goproj/src/mysports
Command: /home/yx/server/go/bin/go test -v
Output:
hello.go:4:2: malformed module path "mysports/utils/crypt": missing dot in first path element
Elapsed: 0.098s
Result: Error

/home/yx/goproj/src/mysports
|--hello_test.go
|--hello.go
|--go.mod
|--README.md
|--go.sum
|--utils
| |--crypt
| | |--go.mod
| | |--crypt_test.go
| | |--crypt.go

@bcmills @me440378

go evn seems correct, but it reports an error

[bcmills]

@AmitShaul @lobo-a, the instances of this error message that you are getting are correct, and are unrelated to GOROOT. See https://blog.golang.org/organizing-go-code#TOC_3..

[eddie-velez]

I continue to get the same "missing dot" error. Is there an official resolution? Nothing in this chain has helped.

[bcmills]

@eddie-velez, if the path is something in the standard library, then the problem is almost certainly your GOROOT setting.

If the path is not something in the standard library, then the error message is likely accurate, and you need to choose an import path that belongs to a (local or fetchable) module; see https://blog.golang.org/organizing-go-code#TOC_3..

[jcburley]

I'm seeing this too all of a sudden. And only on one branch of a fork; another branch, just a few commits behind, has no issues.

So it's not necessarily a problem with how GOROOT is set.

[jcburley]

I'm seeing this too all of a sudden. And only on one branch of a fork; another branch, just a few commits behind, has no issues.

So it's not necessarily a problem with how GOROOT is set.

Indeed, it's a bug in my own recent changes. Hard to find because this project first builds the Go code, then builds another one (a tool called gostd) that is then run and that changes the source for the first, and then re-builds that.

The problem is that the new version of that tool (gostd) introduced these buggy import lines:

import (
        . "core"
)

But I didn't notice those, because those lines are all in files that aren't in the git repo, so git diff didn't show them.

Of course, it would have saved much time if the diagnostic actually pointed to even just one of the problematic files! Instead I was getting this (even on just go clean after running gostd):

build github.com/candid82/joker: cannot load core: malformed module path "core": missing dot in first path element

So maybe this issue should be reopened, in light of this, idea being to improve the diagnostic to point to at least one example of a broken import specification?

[bcmills]

@jcburley

So it's not necessarily a problem with how GOROOT is set.

_This issue_ is about GOROOT as the root cause, since that seems to be the root cause of the original report.

If GOROOT is set correctly, the error message is usually correct — if it weren't, we wouldn't have added that error message in the first place.

[bcmills]

The discussion on this issue seems to be ranging far from the original issue, and we have a new issue filed to track the underlying problem (a less-than-ideal diagnostic when GOROOT is set incorrectly).

If folks are seeing the same issue with the _same_ root cause, please see the tracking issue for that diagnostic.

If folks are seeing the same issue with a _different_ root cause, please try to diagnose it in your code — and if the error message is missing the information you need in order to do that, please open a new issue _with a specific code example and layout that reproduces the problem_.