I'm trying to use godep to install my dependencies but I can't seem to get it to work. When I run GODEP init, I get the following error
determineProjectRoot: /home/cjds/development/core/data-service not in any $GOPATH
But my GOPATH definitely contains that path. This is my whole go path
/home/cjds/development/core/data-service
go install causes the following error, which may be the root of the problem:
no buildable Go source files in /home/cjds/development/core/data-service
The folder structure however has a src folder, and then a main folder and then my whole Go project
-/home/cjds/development/core/data-service/src/main/my-go-files.go
Your GOPATH points to a root directory containing bin, pkg, and src subdirectories, with project source under src. Tools like godep and go install expect to operate on source, not on your entire GOPATH, so must be run on some path under $GOPATH/src.
Related
I have a local Go project which requires another data file to live with it, as in
my_project/
go.mod
my_tool.go
data.txt
go.mod:
module my_project/my_tool
go 1.19
Until today, I had the path to my_project directory inserted in the $PATH environment variable so I could build the executable file with go build and run it from anywhere.
Then I wanted to try and run go install (with no arguments, as shown in this tutorial) from my_project directory. So I did and noticed that the command does two things:
go install builds the executable file just like go build does;
go install moves the executable file —the file itself, not its symlink— to the $GOPATH/bin directory.
But the go install command does not put any other project file to $GOPATH/pkg/mod — which is a no-go for my tool which requires its buddy data.txt file to be located in the same filepath.Dir(os.Executable()) directory as the executable file.
Neither does the go install my_project/my_tool command. Hence the question:
Is it possible to install a local Go package in the $GOPATH directory in such a way that it can find the location of the other files belonging to the project without me having to add the project directory to $PATH?
I cloned code here: https://github.com/kkdai/line-login-go.
I deployed on heroku and ran successfully. But I get: cannot find package on VSCode
Normally, if I put the project in the src directory, and set GOPATH, it will not report an error.
But this project doesn't follow that structure, packages are in the vendor/ directory.
What do I have to do to handle the error?
You could try and use/add go modules to your cloned project (with Go 1.11+, and GO111MODULE=on set):
go mod init github.com/kkdai/line-login-go
go mod vendor
Then you should have all missing dependencies added to your vendor folder.
And you would not even need GOPATH anymore.
As seen in kardianos/govendor/issue 424, go mod should recognize vendor/vendor.json and import the right references previously declared and managed by govendor.
My golang version is go1.10.2 linux/amd64. I can build and run my go project(under gopath/src) without any problem but I cannot see vendor directory under my project folder. I would like to know if the vendor folder is a hidden directory? What are the possible reasons the vendor folder is not generated?
Vendor directory is used as an alternative to GOPATH when resolving dependencies. A dependency is first looked up in /vendor then in GOPATH then in GOROOT.
If you go get all your dependencies they'll be in GOPATH/src instead of /vendor.
To start adding project specific dependencies to vendor dir you need to use a dependency manager such as glide or dep or manually copy everything to /vendor.
This SO answer goes into more detail on using vendor dir in Go - https://stackoverflow.com/a/37238226/1589165
Everything I read about the vendor directory gives me the understanding that if I have a directory:
$GOPATH/src/vendor
And put my dependencies in there (I am using godeps), when doing go run, go should check in that directory first.
If I run my code in a Docker image I have, this works fine. However now that I try to run the same code on my Windows machine, go simply ignores the vendor/ directory, and fails to find the dependencies.
What am I doing wrong?
main.go:7:2: cannot find package "gopkg.in/alecthomas/kingpin.v2" in any of:
C:\Go\src\gopkg.in\alecthomas\kingpin.v2 (from $GOROOT)
C:\Users\js\dev\my_project\rest\src\gopkg.in\alecthomas\kingpin.v2 (from $GOPATH)
C:\Users\js\dev\go\src\gopkg.in\alecthomas\kingpin.v2
Is the output when I try to do:
go run main.go
A directory vendor/ exists in this directory.
go version go1.7 windows/amd64
The exact commands I run (in windows cmd.exe)
> cd C:\Users\js\dev\my_project\rest\
> set GOPATH=C:\Users\js\dev\my_project\rest\;c:\Users\js\dev\go
> cd src
> dir
...
2016-09-01 23:20 2 923 main.go
...
2016-09-03 01:27 <DIR> vendor
> go run main.go
The reason this did not work is because you are not supposed to put any code directly into the $GOPATH/src/ directory.
The solution is to put your project into a sub-directory like so:
$GOPATH/src/app/*.go
Seems your GOPATH is incorrect?
The GOPATH should specify the location of your workspace i.e. directory containing src, pkg and bin directories at its root.
Try doing
set GOPATH=C:\Users\js\dev\my_project\rest\;c:\Users\js\dev\go
More details at: https://golang.org/doc/code.html
The first thing to understand is that godep save is simply copying dependencies from your $GOPATH to a vendor directory inside your project.
You will have to go get your dependencies first. After you have them in $GOPATH, you can do a godep save to copy the current version to your project, and be assured that even if the version in $GOPATH changes, you will have a fixed version in your project until you explicitly change it via godep.
So, if I have a $GOPATH of /home/me/go_workspace, and a project called $GOPATH/src/github.com/project_x with a dependency of github.com/you/xyz, then I would do go get github.com/you/xyz, and godep save from within my project directory. This would create a vendor folder with the dependency at its current commit inside.
I'm relatively new to Go and I've recently created a project that's going up on GitHub. I've tried to follow guides but there's a pressing question of why my binaries end up in src/?
My layout is like this:
ssm/ - Name of project
LICENSE
README.md
src/ - Source Code
files.go - All my source code is here.
src - The compiled binary ends up here
bin/ - Binaries
I set my $GOPATH to ~/Documents/Programming/Go/. From my gopath, I can't type go build ssm because it cannot find package. If I cd into the directory, it complains it can't load package: package .: no Go source files.
I have to actually go into src and compile there, which means the binary isn't in bin/.
What am I doing wrong?
See https://code.google.com/p/go-wiki/wiki/GithubCodeLayout
To be compatible with go get, your project's package name needs to be fully-qualified under the github.com domain:
$GOPATH/
src/github.com/<user>/ssm/
.git
LICENSE
README.md
files.go
bin/
Note that the base of the git repository (.git) is not the same as the $GOPATH.
Also, go build <package> will output a compiled executable to the current directory. If you want the exe to go to bin/, use go install <package> instead.
Your go code you can kept in a workspace. A workspace contains many source files (git, hg, svm, etc.). The Go tool understand the layout. We don't require Makefile or build.xml here. The basic directory layout is everything. If in any case if you are going to change the file layout, accordingly you need to change the build.
This is the general structure you can follow,
$GOPATH/
src/
github.com/username/repo/
mypkg/
mysrc1.go
mysrc2.go
cmd/mycmd/
main.go
bin/
mycmd
And, this is the standard workspace
$GOPATH/
bin/fixhub # installed binary
pkg/darwin_amd64/ # compiled archives
code.google.com/p/goauth2/oauth.a
github.com/...
src/ # source repositories
code.google.com/p/goauth2/
.hg
oauth # used by package go-github
...
github.com/
golang/lint/... # used by package fixhub
.git
google/go-github/... # used by package fixhub
.git
dsymonds/fixhub/
.git
client.go
cmd/fixhub/fixhub.go # package main
go get fetch many repositories whereas go install builds a binary out of them. It's convenient and easy to go for go development quickly. And, everyone in the go community follows the same. This puts src, bin and pkg into the home directory. And, $HOME/bin is already in our path before creating our workspace.