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

Jump to bottom

proposal: x/tools/gopls: support for per-.go file builds #33595

Closed
myitcv opened this issue Aug 12, 2019 · 8 comments
Closed

proposal: x/tools/gopls: support for per-.go file builds #33595

myitcv opened this issue Aug 12, 2019 · 8 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Projects
Proposals (old)
Milestone
Proposal

Comments

@myitcv
Copy link
Member

myitcv commented Aug 12, 2019

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

$ go version
go version devel +1dc0110bf7 Thu Aug 8 20:38:47 2019 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190727173135-db2fa46ec33c
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.4-0.20190727173135-db2fa46ec33c

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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/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-build070739780=/tmp/go-build -gno-record-gcc-switches"

What did you do?

It's a fairly common (citation required) workflow for people to have a single .go file that defines a main() function and then go run X.go

As things stand, go/packages is oriented around packages (somewhat by definition because of its name)

This issue (and apologies if there is a pre-existing one that covers the same topic, my search turned up blank) is to discuss whether it's worth adding support within gopls for per .go file "builds".

There is some discussion with @eliasnaur on this topic in govim/govim#437

The UI/UX around this is not discussed, but the idea is that a single file is effectively treated as the entire package/"build".

There has been some related discussion about this in previous golang-tools calls in the context of // +build ignore-ed code generators that live in the same directory as the target of the code generation.

cc @stamblerre @ianthehat
@myitcv myitcv added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. gopls Issues related to the Go language server, gopls. labels Aug 12, 2019
@gopherbot gopherbot added this to the Proposal milestone Aug 12, 2019
@myitcv myitcv mentioned this issue Aug 12, 2019
Open
@stamblerre stamblerre changed the title proposal: x/tools/cmd/gopls: support for per-.go file builds proposal: x/tools/gopls: support for per-.go file builds Aug 12, 2019
@rsc
Copy link
Contributor

rsc commented Nov 13, 2019

I don't understand what is being proposed here. Is this issue still relevant?
go/packages lets you load 'x.go' (or 'x.go y.go') just fine, right?

@myitcv
Copy link
Member Author

myitcv commented Nov 13, 2019

As I understand things (although @stamblerre and @ianthehat might be able to correct my understanding/bring it up to date) gopls currently requires a rootURI when in module mode, and that root is the directory containing a module. gopls can support multiple workspace folders (views on the same/different module), but it's all directory oriented. Hence I believe there is still a gap when it comes to single file "builds".

@ianthehat
Copy link

Yes, there is a gap, gopls expects that it is working with a rooted project where running packages.Load with ./... in the root path would tell it the entire set of packages it has to consider.
Handing the go command a list of go files is just a special way of describing a package (rather than using the file system to do it)
Personally, I don't think it is a gap worth filling right now, I think it is a niche edge case that only happens when you are jumping though hoops to start with, and any way to describe to gopls the complete set of possible combinations of files and build tags that are being used would overly complicated to the point of uselessness, but I am willing to be convinced otherwise by strong evidence.

@stamblerre
Copy link
Contributor

#34160 is probably a good starting point for this, right?

@rsc rsc added this to Incoming in Proposals (old) Dec 4, 2019
@rsc
Copy link
Contributor

rsc commented Apr 8, 2020

@stamblerre, @myitcv, what's the status of this?
Is there general agreement that we should do it, and it's just in the backlog,
or is there a need for discussion about whether to do it?

@rsc rsc moved this from Incoming to Active in Proposals (old) Apr 8, 2020
@cespare
Copy link
Contributor

cespare commented Apr 8, 2020

Can we at least do this for // +build ignored files? (That is, assume that they're single-file packages.) I deal with these all the time (for code generation, or for little one-off programs/scripts) and it's a hassle that gopls doesn't handle them. I don't think it's a "niche edge case" or that I'm "jumping through hoops" in any way whatsoever. Search for // +build ignore in the Go source tree and you can see that I'm not the only one.

@rsc rsc mentioned this issue Apr 8, 2020
Open
@myitcv
Copy link
Member Author

myitcv commented Apr 9, 2020

@stamblerre will defer to you on whether we keep this open or flip over to #34160

@stamblerre
Copy link
Contributor

stamblerre commented Apr 10, 2020 •
edited

This issue is really a combination of #34160 and the general need for better build tag support (#29202). Let's start with #34160, and then // +build ignore will be addressed as part of build tag support in general, as we definitely intend to support it.

@rsc rsc moved this from Active to Declined in Proposals (old) Apr 15, 2020
@myitcv myitcv mentioned this issue Sep 4, 2020
Open
@golang golang locked and limited conversation to collaborators Apr 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Projects
No open projects
Proposals (old)
Declined
Milestone
Proposal
Development

No branches or pull requests
6 participants
@rsc @cespare @ianthehat @myitcv @stamblerre @gopherbot