Skip to content

x/tools/gopls: "no package for ..." even after added to go.mod #36310

Closed
@JAicewizard

Description

@JAicewizard

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

$ go version
go version go1.13.5 linux/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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jaap/.cache/go-build"
GOENV="/home/jaap/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jaap/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jaap/go-projects/generator/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build223975312=/tmp/go-build -gno-record-gcc-switches"

What did you do?

puts package in import -> no package for ...
go mod tidy -> no package for ...
go mod vendor (without previously existing vendor folder) -> no package for ...
reloading file -> no error
removing the import statement and adding it back -> no error

What did you expect to see?

there should be no error in the first place since it is a valid package and after go mod tidy even has a version attached to it

Activity

added
goplsIssues related to the Go language server, gopls.
on Dec 29, 2019
stamblerre

stamblerre commented on Dec 30, 2019

@stamblerre
Contributor

To clarify, this package was not yet in the module cache?

deleted a comment from gopherbot on Dec 30, 2019
added this to the gopls v1.0 milestone on Dec 30, 2019
added
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
on Dec 30, 2019
JAicewizard

JAicewizard commented on Dec 30, 2019

@JAicewizard
Author

This module is completely new, and doing the same thing with the same module again wont trigger this behavior.
After clearing the module cache using go clean --modcache this behavior can be replicated again with the same module.
So yes this has probably something to do with module cache.

ridersofrohan

ridersofrohan commented on Feb 27, 2020

@ridersofrohan

@stamblerre this should work now, right?

stamblerre

stamblerre commented on Mar 3, 2020

@stamblerre
Contributor

I think so.

@JAicewizard: With the new tempModfile setting and Go 1.14, the workflow of adding a new module should be completely different than it once was. I think we can close this issue out -- please open a new issue if you encounter a problem with the new workflow. I don't think we'll be backporting any fixes to work with Go 1.13.

locked and limited conversation to collaborators on Jul 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.goplsIssues related to the Go language server, gopls.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ridersofrohan@stamblerre@gopherbot@JAicewizard

        Issue actions

          x/tools/gopls: "no package for ..." even after added to go.mod · Issue #36310 · golang/go