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.
Related
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.
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.
Most of the golang tools like golint, gopkgs etc are installed like libraries with go get for instance, go get -v github.com/golang/lint/golint or go get -v github.com/tpng/gopkgs. I wonder why these are not just binaries that run through the source code, like go fmt, for example?
Since I work on multiple Go projects at the same time, I prefer having different GOPATH for different projects and so I am having to install these tools into every single project so that I can lint or have auto completions.
Am I doing something wrong or is there a way to install these tools globally and then just use them in multiple projects? How do people handling multiple projects manage this?
EDIT:
I am not asking about vendoring of libraries or about projects using different versions of Go at the same time. My question is about having to install tools like lint and gopkgs into every GOPATH, why they were designed to be treated like libraries instead of being provided as a global binary like go fmt which then could've been used in multiple projects, just like we use go fmt
so I am having to install these tools into every single project so that I can lint or have auto completions.
No you don't: see how Visual Studio Code does it through its Microsoft vscode-go plugin (since its 0.6.53 version, January 2017).
New setting go.toolsGopath, for providing an alternate location to install all the Go tools that the extension depends on, if you don't want them cluttering your GOPATH.
See PR 351 and PR 737
The tools installed in that one common `` folder are:
'gocode': 'github.com/nsf/gocode',
'gopkgs': 'github.com/tpng/gopkgs',
'go-outline': 'github.com/ramya-rao-a/go-outline',
'go-symbols': 'github.com/acroca/go-symbols',
'guru': 'golang.org/x/tools/cmd/guru',
'gorename': 'golang.org/x/tools/cmd/gorename',
'gomodifytags': 'github.com/fatih/gomodifytags',
'impl': 'github.com/josharian/impl'
(and a few others, around godoc, goimports or goreturns, dlv, ...),
That means your GOPATH is composed of:
your project-specific workspace folder
a global go.toolsGopath workspace folder dedicated to tools used by all projects.
The tools are installed/updated in the bin/ subfolder of that latter workspace.
You can do that manually too (without Visual Studio Code): simply set GOPATH to that global tools folder whenever you want to install/update the tools.
Then reset GOPATH to my/project/dedicated/workspace;/tools/workspace, and add both bin/ subfolders to your $PATH/%PATH%.
The OP Nithin adds in the comments:
these tools can be compiled to binaries and if those binaries are available in $PATH, most editors, as far as I tested (based on your post), both vscode and atom (go-plus) will work and wont go get them again.
It is easier to update if they are treated like libraries. (I mean go get)
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.
I'm currently developing a service that can be built as windows service or run as OSX/linux executable.
I'm using build tags on windows files, including the one with a main method
// +build windows
And on the other file containing a main method
// +build !windows
When I execute go run *.go on the mac side, I get the following error
mainDOS.go:10:2: no buildable Go source files in /Users/michaelbrandenburg/Documents/git-repo/goCode/src/golang.org/x/sys/windows/svc
windowsService.go:15:2: no buildable Go source files in /Users/michaelbrandenburg/Documents/git-repo/goCode/src/golang.org/x/sys/windows/svc/debug
install.go:14:2: no buildable Go source files in /Users/michaelbrandenburg/Documents/git-repo/goCode/src/golang.org/x/sys/windows/svc/eventlog
install.go:15:2: no buildable Go source files in /Users/michaelbrandenburg/Documents/git-repo/goCode/src/golang.org/x/sys/windows/svc/mgr
Is there a way to run go run and target the architecture I want to run? I can build the executables with no problem.
GOOS=darwin go run *.go will set the env for Mac OSX. Though, like JimB said, there isn't much of a point. Doing GOOS=darwin go build *.go is a good way to cross compile though