Asking to see what the appropriate workaround is for building individual go packages from the go/std library when working on a github repo fork. The issue encountered is summarized by the following error when building for example the src/go/parser package.
parser.go 21:2 use of internal package go/internal/typeparams is not allowed
Of course the project import paths all reference GOROOT library paths
usr/local/go
And I am typically working on projects from my own directory where my go path is set.
/Users/andewx/github/go/src/github.com/andewx/my_go_extension_project
The crux of the issue is that the clone/fork project uses standard library import paths and I would like to be able to work on my repo from my own GOPATH. But internal packages can't be imported in this case because the import directives will always point to my GOROOT.
The only two options I can think of is:
Extending my personal go project by initiating the repo inside of my /usr/local/go and working on the packages from there.
Changing my GOROOT to point to my current project and including current go binary go fmt and toolchains in my project
Ideally I can just leave everything as far as directory structure is concerned as is and I can redirect the standard import path for go standard library to my current project for this project only...
Any ideas from the community for solution #3 is what I'm looking for.
Extending my personal go project by initiating the repo inside of my /usr/local/go and working on the packages from there.
Changing my GOROOT to point to my current project and including current go binary go fmt and toolchains in my project
If you are trying to work on the go compiler and extend it I actually found that changing your GOROOT to point to your workspace and then copying over the binaries and tools you need as a suitable fix and it doesn't create any additional issues.
Export your environment variable export GOROOT="/my/go/project"
Find out where your go tools are located with go env GOTOOLDIR copy this directory structure into your project folder.
Copy go bin cp /usr/local/bin/* ${GOROOT}"/bin" copy in your go binary
Copy toolscp /usr/local/go/pkg/tool/linux_amd64/* ${GOROOT}/pkg/tool/linux_amd64
Now your project should be able to run the copied binaries with your project directories temporarily set as the GOROOT.
Related
I'm working in fibrechannel project, and there are same level project(common) that fibrechannel depends on.
When I select Enable Go modules integration as below:
IDE tells me logger not found. (Note I'm using red rectangle to mark the reference and it's actually location under common folder)
After I unclick the Enable Go modules integration checkbox. (Note GOPATH looks like below)
IDE tells me "github.com/pkg/errors" not found.
the go.mod under fibrechannel looks like below:
module fibrechannel/src
go 1.12
require (
github.com/pkg/errors v0.8.1
github.com/stretchr/testify v1.3.0
gopkg.in/iconv.v1 v1.1.1
gopkg.in/yaml.v2 v2.2.2
)
I'm a newbie in GO language, and I just want the IDE to resolve dependencies successfully.
I'm wondering if there's a way to make both GOPATH and GoModules work in Jetbrains GoLand. If not, is there a way to modify go.mod so that it can include GOPATH?
Finally, I managed to solve this issue.
B.T.W, since this is an old project maintained by many team members. I don't want to change its code structure, all I need is to read the content without any unknown reference in GoLand.
The solution is NOT to use go modules.
I unchecked the Enable Go modules integration so that only libraries in venders folder not found.
Then I manually added venders folder into GOPATH.
Now dependencies are all resolved!
Not having previous knowledge about creating a project from zero within terminal, I've created a folder, cd into of it then run go mod init my_project_name which created a go.mod file for me, then I've created main.go file which built just ok.
Then I created a folder and add a go file inside with package name (being same with directory) and create a struct inside of it. Next I tried to import that package in main package but when I try to build on terminal it gave me this error
go: cannot determine module path for source directory /Users/berkcan/workspace/go/my_project_name (outside GOPATH, module path must be specified)
After googling and not being able to find a solution to my problem, I've imported project to beloved Intellij IDE and I enabled Go modules integration then everything worked flawlessly. First I thought IDE doing some magic inside while building project but even when I try go build command in terminal, it built. But I cant see difference in project structure or a new line in go.mod file.
So what happened, what did Intellij IDE did when I ticked go module integration box and what I can do enable it on terminal without Intellij IDE ?
here is the photo of option in IDE when ticked
IntelliJ IDEA plus Go plugin or GoLand under the hood has two modes to get the information about your packages (simplified):
GOPATH. IDEA scans your $GOPATH directory to build internal indexes of your packages and provides code completion, resolving, etc.
Go Modules. IDEA executes go list -m -json to resolve your dependencies and scans your $GOPATH/pkg/mod directory (default value of GOMODCACHE) for the packages. If they don't exist, IDEA executes go mod download. After these operations, the IDE provides all built-in features like code completion, navigation and so on.
Both modes don't change your Go or environment variables as well as behavior in the terminal. When you check Enable Go Modules integration option in the settings, the IDE just switches the mode from scan $GOPATH to execute go list and resolve your dependencies from the Go Modules cache.
To summarize, IntelliJ IDEA doesn't do any magic. I suppose it relates to your custom Go environment variables inside the terminal, especially GO111MODULE and if you didn't pass these variables to the GUI apps (e.g. you have specified it in .zshrc file and run the IDE via Desktop entry instead of the terminal), IntelliJ IDEA doesn't inherit them. You can compare go env output inside your local terminal and built-in inside the IDE (View | Tool Windows | Terminal) and find differences.
I've just installed Golang on my machine, and I set up GOPATH.
But when I navigate to my go/src I see that src folder contains ./sourcegraph.com, ./golang.org and ./github.com. Also GOPATH/bin and GOPATH/pkg also no empty.
So I have several questions:
1) I know how to use ./github.com folder for pushing my code to github, but why it contains , from box, some other not mine projects inside such as acroca, cweil ... and other ? Can I clear this folder?
2) What I should do with golang.org folder, can I remove it ?
3) What I should do with sourcegraph.com folder, can I remove it ?
4) Can I clear bin and pkg from preinstalled binaries and packages?
I think you not only installed the Golang but also install/configure Visual Studio Code IDE with Go Extension. Those alien repositories were created when the extension installs needed tools. The full list of tools can be found here. Or probably other similar IDE/extension which depends on those tools.
Yes you can clear the sources, since the IDE depends only on the compiled binary, and the sources are only needed during compilation.
Same as (1). Refers to Golang SubRepositories
Same as (1)
For now, you can clear the content of pkg directory but don't remove the directory. In the future, when you install some packages/libraries, the compiled version may be created under the directories, so don't remove it. For bin directory, don't remove the files inside it, because the IDE (Go Extension) depends on them.
But, since I don't know exactly what else you've done, I think before you completely remove them, try just to move them outside your GOPATH or take a backup and see whether your dev environment works as expected.
Setting the GOPATH variable global as an enviroment variable works fine with Visual Studio Code.
But setting a project specific variable globally doesn't seem very nice to me. Consider you have multiple Go projects, you would have to change this variable each time you, compile, debug, ... etc. a project.
Is there a possibility to set the GOPATH variable as a project variable in Visual Studio Code? Ether in settings.json or launch.json?
(Q2 2018:
Note that with the vgo project, GOPATH might end up being deprecated in favor of a project-based workflow. That would avoid the manual project-based GOPATH I was proposing below, two years ago)
With Go 1.11 (August 2018), GOPATH can be optional, with modules.
It is more and more supported with VSCode:
vscode-go/issue 1532
"Go modules support in Visual Studio Code"
In addition to vendor folder, you still can have one GOPATH per project.
See "GOPATH from go.inferGopath setting":
GOPATH from go.inferGopath setting
Setting go.inferGopath overrides all of the above.
If go.inferGopath is set to true, the extension will try to infer the GOPATH from the path of the workspace i.e. the directory opened in vscode. It searches upwards in the path for the src directory, and sets GOPATH to one level above that.
For example, if your project looks like /aaa/bbb/ccc/src/..., then opening the directory /aaa/bbb/ccc/src (or anything below that) will cause the extension to search upwards, find the src component in the path, and set the GOPATH to one level above that i.e. GOPATH=/aaa/bbb/ccc.
This setting is useful when you are working on different Go projects which have different GOPATHs. Instead of setting the GOPATH in the workspace settings of each project or setting all the paths as ;/: separated string, you can just set go.inferGopath to true and the extension uses the right GOPATH automatically.
GOPATH for installing the Go tools using go.toolsGopath
By default, all the dependent Go tools are used from the GOPATH derived from the above logic.
If they are available on your PATH, the PATH is used to locate the Go tools.
If the Go tools are not in your path, you might end up with the same Go tools installed in each of your GOPATHs.
To prevent the Go tools from cluttering your GOPATH, use the go.toolsGopath setting to provide a separate location for the Go tools.
The first time you set go.toolsGopath, you will have to run Go: Install Tools command so that the Go tools get installed in the provided location.
set workspace settings, in windows:
goto settings: ctrl+,
set workspace setting:
{
"go.gopath": "d:\\gopath;E:\\src"
}
use ; for multiple path
restart visual studio code to take effect.
The GOPATH is your workspace and it's divided in
GOPATH/
|- bin/
|- pkg/
|- src/ <--- your projects are saved here
|- .../my_project1
|- .../my_project2
With this separation, your don't need to set a new GOPATH for each project. I recommend you read How to Write Go Code
Go 1.5 added the vendor directory that allows a per-project dependency management.
If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that path names a directory containing at least one file with a name ending in “.go”.
source
This feature has been enabled by default with Go 1.6:
Go 1.5 introduced experimental support for a “vendor” directory that was enabled by an environment variable. In Go 1.6, the feature is now enabled by default.
source
Even with the 1.6 version, depending on the tools you use, you might need to set the GO15VENDOREXPERIMENT environment variable to 1 (export GO15VENDOREXPERIMENT=1 on unix-based OS)
If your VSCode project directory is organized,
go to Settings
either search "Infer Gopath" or find this entry under Extensions/Go
check the box
Then VSCode infers GOPATH from your workspace root, which solves my problem immediately. I believe this is explained in other answers. I am posting this just to give a shorter version.
The way I have my projects structured is similar to the following
/workspace
/src
/package1
/vendor
/src
/somepackage
/anotherpackage
/package1
My GOPATH is set to /workspace;/workspace/vendor
Note this is not using the go 1.5 vendor option.
So far everything has been compiling and working fine within out build / development workflow.
I'm in a situation now where I would like to import a library into the vendor directory workspace/vendor/src/package1 but write some unit tests in the workspace/src/package1 directory..
When the tests run it cannot find methods from the package1 in the vendor dir.
Is there a way to get the vendor package code recognised into the same namespace like this?
Are you asking to essentially "split" the code for a package between two folders in two different gopaths? The go tool cannot do this, as it takes the first folder it finds on any folder in your gopath. If you are actively working on a project, why would it go in the vendor gopath and not in the src one?
It is because of distinctions like this that I generally recommend one gopath for everything. If you want to vendor dependencies I recommend doing that for each individual main package you have.
As captncraig said: The go tool cannot do this.
But you are free to call the go compiler itself on any set of files you want: go tool compile <file.go>...
Of course this would reintroduce some kind of Makefile style build system. It is doable but all the heavy lifting done by go build or go install is lost and will have to live in your Makefiles.