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

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

myitcv opened this issue Aug 12, 2019 · 8 comments

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

myitcv opened this issue Aug 12, 2019 · 8 comments


Copy link

@myitcv 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 v0.0.0-20190727173135-db2fa46ec33c
$ go list -m v0.1.4-0.20190727173135-db2fa46ec33c

Does this issue reproduce with the latest release?


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

go env Output
$ go env
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

@gopherbot gopherbot added this to the Proposal milestone Aug 12, 2019
@gopherbot gopherbot added the Proposal label Aug 12, 2019
@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
Copy link

@rsc 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?

Copy link
Member Author

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

Copy link

@ianthehat ianthehat commented Nov 13, 2019

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.

Copy link

@stamblerre stamblerre commented Nov 13, 2019

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

@rsc rsc added this to Incoming in Proposals Dec 4, 2019
Copy link

@rsc 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 Apr 8, 2020
Copy link

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

Copy link
Member Author

@myitcv myitcv commented Apr 9, 2020

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

Copy link

@stamblerre stamblerre commented Apr 10, 2020

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.

@stamblerre stamblerre closed this Apr 10, 2020
@rsc rsc moved this from Active to Declined in Proposals Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.