Skip to content
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

x/tools/gopls: automate daily updates of gopls/go.mod #34952

Open
ainar-g opened this issue Oct 17, 2019 · 10 comments

Comments

@ainar-g
Copy link
Contributor

@ainar-g ainar-g commented Oct 17, 2019

Not sure if there's something wrong with my installation or the repo. Here's what I try to do, and what used to work before:

Shell log
$ go version
go version go1.13.1 linux/amd64
$ go clean -cache -modcache
$ go get golang.org/x/tools/gopls@master
go: finding golang.org/x/tools/gopls master
go: downloading golang.org/x/tools/gopls v0.0.0-20191017101817-846f856e7d71
go: extracting golang.org/x/tools/gopls v0.0.0-20191017101817-846f856e7d71
go: downloading golang.org/x/tools v0.0.0-20190918214516-5a1a30219888
go: extracting golang.org/x/tools v0.0.0-20190918214516-5a1a30219888
go: downloading honnef.co/go/tools v0.0.1-2019.2.3
go: downloading github.com/sergi/go-diff v1.0.0
go: downloading golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7
go: downloading golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: extracting github.com/sergi/go-diff v1.0.0
go: extracting golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: extracting golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7
go: extracting honnef.co/go/tools v0.0.1-2019.2.3
go: downloading github.com/BurntSushi/toml v0.3.1
go: extracting github.com/BurntSushi/toml v0.3.1
go: finding github.com/sergi/go-diff v1.0.0
go: finding golang.org/x/tools v0.0.0-20190918214516-5a1a30219888
go: finding honnef.co/go/tools v0.0.1-2019.2.3
go: finding golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: finding golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7
go: finding github.com/BurntSushi/toml v0.3.1
# golang.org/x/tools/gopls/internal/hooks
../../../../pkg/mod/golang.org/x/tools/gopls@v0.0.0-20191017101817-846f856e7d71/internal/hooks/analysis.go:15:12: options.StaticCheck undefined (type *source.Options has no field or method StaticCheck)
../../../../pkg/mod/golang.org/x/tools/gopls@v0.0.0-20191017101817-846f856e7d71/internal/hooks/analysis.go:17:11: options.Analyzers undefined (type *source.Options has no field or method Analyzers)
../../../../pkg/mod/golang.org/x/tools/gopls@v0.0.0-20191017101817-846f856e7d71/internal/hooks/analysis.go:20:11: options.Analyzers undefined (type *source.Options has no field or method Analyzers)
../../../../pkg/mod/golang.org/x/tools/gopls@v0.0.0-20191017101817-846f856e7d71/internal/hooks/analysis.go:23:11: options.Analyzers undefined (type *source.Options has no field or method Analyzers)
../../../../pkg/mod/golang.org/x/tools/gopls@v0.0.0-20191017101817-846f856e7d71/internal/hooks/hooks.go:15:12: options.GoDiff undefined (type *source.Options has no field or method GoDiff)
../../../../pkg/mod/golang.org/x/tools/gopls@v0.0.0-20191017101817-846f856e7d71/internal/hooks/hooks.go:16:10: options.ComputeEdits undefined (type *source.Options has no field or method ComputeEdits)

EDIT: A colleague of mine has the same issue.

@gopherbot gopherbot added this to the Unreleased milestone Oct 17, 2019
@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Oct 17, 2019

Thanks for reporting, I can reproduce it too. It's a build problem on golang/tools@846f856 commit (edit: it happens only when gopls isn't the main module and its replace directive is ignored). /cc @stamblerre

For some reason, the builders didn't catch this failure. I'll look into that.

If you just want to install the latest released version, you can use go get golang.org/x/tools/gopls@latest instead of @master as suggested in https://github.com/golang/tools/blob/master/gopls/doc/user.md#installation.

@fsouza

This comment has been minimized.

Copy link
Contributor

@fsouza fsouza commented Oct 17, 2019

The problem is that gopls uses replace, and go get won't honor that. An alternative is to manually clone the repo and run go install.

@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Oct 17, 2019

@fsouza Thanks, that explains why builders didn't catch it. The replace directive was used during tests because go test ./... ran inside gopls directory and so it was the main module.

@ainar-g

This comment has been minimized.

Copy link
Contributor Author

@ainar-g ainar-g commented Oct 17, 2019

@dmitshur I know about @latest, but I specifically get @master from time to time to report bugs like this ASAP :-)

Is there an issue about go get not respecting replace directives? Should I create one?

@fsouza

This comment has been minimized.

Copy link
Contributor

@fsouza fsouza commented Oct 17, 2019

Maybe #30515?

See comment: #30515 (comment)

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Oct 17, 2019

I think the issue is that we just haven't updated the go.mod file for gopls in a while, so it's relying on an old version of x/tools, so I wouldn't expect that command to work outside of the tools module. Because of the replace directive, the correct way to install gopls at master would be to clone the repo and run go install inside of the gopls directory.

@zikaeroh

This comment has been minimized.

Copy link

@zikaeroh zikaeroh commented Oct 19, 2019

I typically pull gopls and x/tools together, i.e. golang.org/x/tools/gopls@master golang.org/x/tools@master, since I like to live on the edge and run master all the time. Since x/tools and gopls don't really place nicely due to internal package changes, you basically have to run latest of gopls, or master of both.

(Technically, I use a custom tool I wrote to manage binaries with modules which can copy upstream replacements to a local mod file, though admittedly not relative ones at the moment.)

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Oct 21, 2019

I ran into this and worked around it by making my own go.mod that pulls up the x/tools version to one that works with gopls.

module my/gopls

go 1.13

require (
	golang.org/x/tools v0.0.0-20191018212557-ed542cd5b28a // indirect
	golang.org/x/tools/gopls v0.0.0-20191018212557-ed542cd5b28a // indirect
)

It feels like the go.mod of golang.org/x/tools/gopls should have a working version at all times (as tested by the builders), or a completely fake one (like v0.0.0, so the build will fail more obviously), if the only allowed way to build is with gopls as the main module.

FiloSottile added a commit to FiloSottile/mostly-harmless that referenced this issue Oct 21, 2019
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Oct 25, 2019

Totally agree that getting gopls@master should always work. We really ought to have some automation around updating the go.mod daily, or something like that.

@stamblerre stamblerre changed the title x/tools/gopls: go get golang.org/x/tools/gopls@master fails x/tools/gopls: automate daily updates of gopls/go.mod Oct 25, 2019
@zikaeroh

This comment has been minimized.

Copy link

@zikaeroh zikaeroh commented Oct 25, 2019

I will be curious about how the new -g option going into 1.14 will help in this case. Since it effectively installs something using the tool's module as the main module, replacements will probably work and the ../ replacement for x/tools might just work.

EDIT: Based on the discussion in the -g thread, I'm not so sure it's going to end up being equivalent to cloning gopls and running go install in it. Unfortunate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.