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

Open
myitcv opened this issue Aug 12, 2019 · 4 comments
Open

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

myitcv opened this issue Aug 12, 2019 · 4 comments

Comments

@myitcv
Copy link
Member

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

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

This comment has been minimized.

Copy link
Contributor

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

@myitcv

This comment has been minimized.

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

@ianthehat

This comment has been minimized.

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.

@stamblerre

This comment has been minimized.

Copy link
Contributor

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
5 participants
You can’t perform that action at this time.