I have used VS Code as my code editor for building service using Go for almost one year. Then, I tried to switch to GoLand. But, when I tried run a test function there is an error: cannot find package "." What is the problem?
Note: I use go module as go dependency management tool. When I use dep (in another project), there is no error when running a test function. My project is in GOPATH.
Please make sure there's a valid go.mod file defined at the ROOT of your project i.e. in $GOPATH/src/<Project-name>.
If you don't have, you can create one using go mod init command using the shell. More information on the same - https://github.com/golang/go/wiki/Modules
After that please try running the test from the shell. First cd into the directory where the test file is present. Then, use go test . -test "<TestName>" -v to run your test. If the issue goes away, you can run the test from IDE and it should work fine.
Related
I am using the primary GO extension.
I use VS code a lot, now I'm learning GO lang.
And when I open VS Code every time I'm getting this:
Error loading workspace: found module "main.go" twice in the workspace.
While running the code it's giving the right output.
I don't know how to fix this.
Anybody, help me with this error.
It would be better to open in VSCode only one folder with its own go.mod project.
A workspace with multiple go.mod/project should be supported with 1.18
The go command now supports a "Workspace" mode.
If a go.work file is found in the working directory or a parent directory, or one is specified using the -workfile flag, it will put the go command into workspace mode.
In workspace mode, the go.work file will be used to determine the set of main modules used as the roots for module resolution, instead of using the normally-found go.mod file to specify the single main module.
As described in "How to make VScode Go work in a Multi-Module Repo" from Varun Kumar, this used to work:
If you want to work with all the nested modules in a single workspace, there is an opt-in module feature that allows to work with multiple modules without creating workspace folders for each module. Set this in your settings -
"build.experimentalWorkspaceModule": true
But as per september 2022 is deprecated.
See more at gopls documentation "Setting up your workspace".
I'm new to golang. I'm currently trying to use the godror driver to read from an Oracle db. I ran go get github.com/godror/godror in my project's root directory and am importing the library like so:
_ "github.com/godror/godror"
But, I'm getting the error
cannot find package "." in:
/test_repo/vendor/github.com/godror/godror"
I believe my PATH is set up properly, as the "go" command properly returns the expected "Go is a tool for managing Go source code..." response.
I can't exactly replicate your issue nor have I seen such a weird error - but regardless, if you were following the current go modules pattern you wouldn't have this issue to begin with.
You shouldn't run go get anymore to download modules to use for your programs. Instead, in the root directory of every go project, you'll run go mod init [modulename], which will create a go.mod file for you. After running go mod tidy, it will download all the dependencies and generate a go.sum file containing the dependency hashes for you as well. Next, running go build will generate a binary that you can run. At this point, if you make changes to any source file(s), running go build every subsequent time afterwards will make a new, updated binary in the same directory.
I am testing this very simple Go code on MacOS using VS Code. The project consists of these sample packages / files:
azure.com/myproj/cmd/service/main/main.go
azure.com/myproj/cmd/service/service.go
azure.com/myproj/cmd/service/tests/test.go
azure.com/myproj/internal/common/common.go
On the terminal command line, everything builds and all tests pass:
go build . // (works in every folder)
go test . // (tests work and pass)
However, from VS code I have 2 problems:
1. Imports from package to package do not work at all. For example:
package test
import (
service "azure.com/myproj/cmd/service" // VS complains on this line when running the test.
)
The command that VS code runs is not just "go test . ". It passes extra parameters that include what seems to be a cached path, which I tried deleting from the file system, but it did not have an effect. This is what VS.code's Output tab contains:
Go Tests tab:
unknown import path "azure.com/myproj/cmd/service":
cannot find module providing package
azure.com/myproj/cmd/service
Go tab:
/Users/computername/go/src/azure.com/projname/cmd/service/tests
>Finished running tool: /usr/local/bin/go test -c -o
/var/folders/q5/hm9v_6x53lj0gj02yxqtkmd40000gn/T/vscode-goKGOMES/go- code-check azure.com/myproj/cmd/service/tests
can't load package: package
azure.com/myproj/cmd/service: unknown import path
"azure.com/myproj/cmd/service": cannot find module
providing package azure.com/myproj/cmd/service
I do not understand what VS code is doing above with hm9v_6x53lj0gj02yxqtkmd40000gn and how I can change it. It looks like a cache.
So to summarize: When testing through VS Code, i do not understand why it's using the command that it is to run the tests (above), and why it can not find the imports, which the regular "go build . " and "go test . " commands have no problem with through the terminal.
Once again: From the terminal command line everything builds and all tests pass.
Seems to clearly be a VS Code related issue.
I found the answer to my problem. VS did not like the file path structure for the project. Here are the changes I made:
Moved main.go from azure.com/myproj/cmd/service/main/main.go up a level to azure.com/myproj/cmd/service/main.go
Moved the service implementation (service.go) into the internal folder: azure.com/myproj/internal/service/service.go
Moved the tests into the internal folder:
azure.com/myproj/internal/service/test/service_test.go
How VS code is able to run the tests without complaining of the imports not being found.
So now I only have the main.go in my /cmd/service folder. Everything lives in Internal, including tests. I suspect that burying main.go into a subfolder is what was confusing VS Code.
My app is packaged as the following:
|-cmd/
|-cmd/application/ <- this contains the main.go and other files
|-internal/ <- contains internal dependencies
|-vendor/ <- contains third party libraries
And when running the following command from the root /:
go build cmd/application/*.go
It produces an executable that works fine. But when typing the following command from inside /cmd/application:
go build my_app_custom_name
I get the Syntax error: newline unexpected error, as if it wasn't a bash executable anymore.
With the help of the indication #Volker after using the flags -v and -x I figured out that I was naming the package "myapp" and not "main" as it should be. Now it works just fine.
As said by #Kaedys and #JimB, it is preferable to use the standard form for building apps :
go build // Method one from inside directory with go files
go build full/import/path/of/package/to/build // second method
Note that this is the recommended way in How to write Go code
The other way to build is using go build . and go build *.go in the directory where you go package is.
Getting an error when trying to run go build ./... from my $GOPATH/src .
no non-test Go files in <dir>
The error is correct there are no test files in <dir> but why is that causing a compile error? Is it a bug?
I don't think this is a bug, unless you see somewhere in the docs that contradicts this behaviour you should probably close the issue you've created.
Tests in go normally live in the package they are testing. You have made a new package with package main at the top (invalid if you also have main elsewhere), and then have included no go source files in that tests/main package (invalid as package has no go source files apart from tests, which the compiler complains about explicitly).
Possible solutions for you (assuming this isn't just a hypothetical question):
Move tests for main to test_main.go (this is what readers will
expect)
Add doc.go file to your tests pkg and call it package tests in
both files
The reason for putting tests in the same package is to ensure they have access to the entire package, if you want to split them to another package you'll find you have to test as an external user of the pkg - this may be painful. Main is also a special case as well as you don't normally import it.
Calling it a bug… the build shouldn't fail if the tests compile. Filed here: https://github.com/golang/go/issues/22409
The bug I filed was a duplicate of https://github.com/golang/go/issues/8279 looks like it was broken in 1.3.
First, check your $GOPATH has been set correctly. Learn more at here.
Then, check if any '_' in your file name. Remove these '_'s and try again.
;-)