Closed ConcurrentCrab closed 9 months ago
Ad-hoc package (or no package, or command-line-args
package) support was never a priority, and even with the upcoming zero-config gopls, I am not sure if the build mode without go.mod
will be supported reliably.
Since go1.21, go is moving towards configuring the stdlib and tooling versions using go.mod
, like other third-party dependencies. The go version in go.mod
will become more important - for example, loopvar change proposal (https://go.dev/blog/loopvar-preview) heavily depends on the go.mod
go line value to determine the loop behavior. If so, I am sorry that supporting the scripts without go.mod
will become much less important.
What prevents from having a go.mod
file in the script directory?
Hi @hyangah,
What prevents from having a
go.mod
file in the script directory?
Nothing prevents me from adding one. It just seems weird to me that I am doing something that the language and toolchain allow me to do, but if I want autocomplete in my editor, I am forced to do things a certain different way. Or, more accurately, everything including autocomplete works as-is, but I am made to populate a file (which should ultimately be unnecessary information to the extension) to placate an error message.
Since go1.21, go is moving towards configuring the stdlib and tooling versions using
go.mod
, like other third-party dependencies. The go version ingo.mod
will become more important - for example, loopvar change proposal (https://go.dev/blog/loopvar-preview) heavily depends on thego.mod
go line value to determine the loop behavior. If so, I am sorry that supporting the scripts withoutgo.mod
will become much less important.
I don't think this is a new development, really. Go tooling, including build
and vet
, has had diverging behavior depending on the specified version for quite a while. The most well-known example would probably be the whole old GOPATH
vs. modules debacle. When you run
or vet
standalone go files, the toolchain assumes it was written for the most up-to-date language version, and treats it with those semantics.
The way I see it, standalone go run
scripts having an unspecified version means it falls under a contract much like scripts in traditional interpreted languages, like python or bash, where either you specify the version it was created under as part of documentation (e.g. in comments), or you make sure it has no non-trivial behavior that behaves "controversially" across versions. And I'm fine with that contract personally.
Zero-config gopls work will handle the ad-hoc package and make it possible to load it independent of go.mod
's presence. See https://github.com/golang/go/issues/57979
The work is currently in progress. I will add a note to mention there to make sure the UX is tested. Closing in favor of the zero-config gopls work.
I see, thank you very much @hyangah ! Will be looking forward to the change.
What version of Go, VS Code & VS Code Go extension are you using?
* Run `go version` to get version of Go from _the VS Code integrated terminal_. - go version go1.21.4 windows/amd64 * Run `gopls -v version` to get version of Gopls from _the VS Code integrated terminal_. - golang.org/x/tools/gopls v0.14.2 * Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders. - 1.84.2 * Check your installed extensions to get the version of the VS Code Go extension - v0.40.0 * Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > `Go: Locate Configured Go Tools` command. - ``` Checking configured tools.... GOBIN: undefined toolsGopath: gopath: C:\Users\Ishan\go GOROOT: C:\Users\Ishan\scoop\apps\go\current PATH: C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\dotnet\;C:\Program Files (x86)\Tailscale IPN;C:\Users\Ishan\scoop\apps\vscodium\current\bin;C:\Users\Ishan\go\bin;C:\Users\Ishan\scoop\apps\openssl\current\bin;C:\Users\Ishan\scoop\apps\openjdk\current\bin;C:\Users\Ishan\scoop\apps\imagemagick\current;C:\Users\Ishan\scoop\apps\python\current\Scripts;C:\Users\Ishan\scoop\apps\python\current;C:\Users\Ishan\scoop\apps\mingw\current\bin;C:\Users\Ishan\scoop\apps\qemu\current;C:\Users\Ishan\scoop\apps\mpv\current;C:\Users\Ishan\scoop\shims;C:\Users\Ishan\AppData\Local\Microsoft\WindowsApps go: C:\Users\Ishan\scoop\shims\go.exe: go version go1.21.4 windows/amd64 gopls: C:\Users\Ishan\go\bin\gopls.exe (version: v0.14.2 built with go: go1.21.4) gotests: not installed gomodifytags: not installed impl: not installed goplay: not installed dlv: C:\Users\Ishan\go\bin\dlv.exe (version: v1.21.0 built with go: go1.21.0) staticcheck: C:\Users\Ishan\go\bin\staticcheck.exe (version: v0.4.5 built with go: go1.21.0) go env Workspace Folder (snips): f:\prog\snips set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\Ishan\AppData\Local\go-build set GOENV=C:\Users\Ishan\AppData\Roaming\go\env set GOEXE=.exe set GOEXPERIMENT= set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GOMODCACHE=C:\Users\Ishan\go\pkg\mod set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\Ishan\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Users\Ishan\scoop\apps\go\current set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLCHAIN=auto set GOTOOLDIR=C:\Users\Ishan\scoop\apps\go\current\pkg\tool\windows_amd64 set GOVCS= set GOVERSION=go1.21.4 set GCCGO=gccgo set GOAMD64=v1 set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=NUL set GOWORK= set CGO_CFLAGS=-O2 -g set CGO_CPPFLAGS= set CGO_CXXFLAGS=-O2 -g set CGO_FFLAGS=-O2 -g set CGO_LDFLAGS=-O2 -g set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\Ishan\AppData\Local\Temp\go-build1832283827=/tmp/go-build -gno-record-gcc-switches ```
Share the Go related settings you have added/edited
None
Describe the bug
I have a folder full of scripts I use with
go run
. There is nogo.mod
module, or any other module-related metadata file in the directory.The extension (and
gopls
) doesn't like that at all. It complains about all the redefinedfunc main()
s and everything else as you'd expect it to in an actual package.Now, I am aware of
build.standaloneTags
, and adding//go:build ignore
(sinceignore
is in the default value of that setting) to the top of all those scripts makes almost all those errors go away, except one:To my understanding, that setting is specifically only meant for specifying "standalone" scripts within a proper module, so I guess this does make sense.
Am I missing something obvious, or is there no way to use this extension in this way, with a bunch of loose standalone scripts?
Moreover, why are all these diagnostics kicking in at all without a module being present?
go build
,go build .
all refuse to run in a directory when nogo.mod
is present. Shouldn't the extension follow its behavior, not automatically assuming a module exists, and falling back to a standalone-script mode by default?Steps to reproduce the behavior:
Create a file
hello1.go
:cp hello1.go hello2.go