I am using Go 1.7 and trying out Glide. The part I'm not getting is, Glide creates a vendor directory at $GOPATH/vendor. But when go builds it is looking for a vendor directory at $GOPATH/src/github.com/vendor/.../...
So I'm missing the part that happens between installing/updating dependencies and making them available to my program during a build.
Adding the answer for the next poor soul that comes along.
If you're coming from the Java world, and you are used to the src directory being at the root of your project... Go says you are wrong. As the commenter indicated, your project path is $GOPATH/src/[github.com]/username/projectname and that is where you should do your "glide init".
That will create the glide.yaml file in the correct spot so "glide install" will create the vendor directory at $GOPATH/src/githost/username/projectname/vendor and then your go builds will work as expected.
Hopefully this will clear it up for other folks who might have similar questions.
Related
I'm trying to play around with the lightning network. I have cloned the repo, and on disk placed it here (I'm using windows):
C:\Users\hallibut\Documents\GitHub\lnd
I'd like to run any of the tests in itest, lets say testMultiHopPayments. The cli commands I'm using after I cd into the above location is:
go test itest -run testMultiHopPayments
However, I keep getting the error:
package itest is not in GOROOT (C:\Program Files\Go\src\itest)
I've read through the various posts on this error, but I'm still not quite sure why it happens, and it's likely because I don't fully understand the go module (I'm new to go). This article, was probably the best in helping me understand the structure and env variables:
https://golangbyexample.com/workspace-hello-world-golang/
My understanding from the various readings is that whatever directory the go.mod file is in, indicates the module level directory. Prior to version 1.13 there was a required directory and structure, but now that should not be an issue if you're using at least version 1.13 and modules. I'm using 1.17.1. This is somewhat of an assumption or inference, but I believe everything lower in the directory structure is part of a package to be installed as part of the module (and is defined by the package keyword). However, I don't understand why a package with source code within a subdirectory would be missing/throw the aforementioned error. I've also tried running:
go mod install github.com/lightningnetwork/lnd/lntest/itest
That doesn't seem to do anything/has not effect on the error. What am I not understanding about packages? Looking at the go.mod file I observe that itest is not specifically defined anywhere… Not sure if that's required. Also, I assume I've got to run some build process prior? I attempted this with:
go install -v ./...
If you're using VS Code and Go Modules, you need to "Open folder" and point to the cloned repo, to get around that error
I am trying to download, make some tweaks and build a golang project from GitHub. The project's instructions are:
go get github.com/<vendor>/<projectName>
cd src/github.com/<vendor>/<projectName>
go build .
That used to work in the past — before enabling Go Modules.
Now I have GO111MODULE=on (go version go1.15.4 linux/amd64). When running the first command, go downloads the project as a module and all its dependencies.
But then there is no src/github.com/<vendor>/<projectName> folder anymore. Moreover, the is no folder named <projectName> anywhere in the system.
Instead, there is folder pkg/mod/github.com/<vendor> which contains the project folder with weird symbols in its name (exclamation marks etc.) and version identifiers.
How do I get the project folder available for making tweaks and builds?
As pointed by #Volker, good old git clone should be used.
It turns out that it should be used instead of go get github.com/<vendor>/<projectName> (no idea why the project vendor recommends that):
git clone git://github.com/<vendor>/<projectName>
cd <projectName>
go get ./...
# do tweaks here
go build .
If your goal is tweaks, the easiest way it use to use go mod vendor.
https://golang.org/ref/mod#go-mod-vendor
The go mod vendor command constructs a directory named vendor in the main module's root directory that contains copies of all packages needed to support builds and tests of packages in the main module
I am trying to install chromaticity on my own machine for testing, and no matter what i do i will always hit the error seen in this picture installation error
I dont know why it happened i tried searching but i found nothing online. my question is does anyone know why it happens? or can point me to the right direction? i have checked the folders and yes there are no GO files in there but i dont see why that is a problem
The api could be found here: https://github.com/evq/chromaticity
This is not an issue (as in bug) on the project, rather an issue due to lack of documentation on how to build the project itself.
If you look at the Makefile file on the root directory, you'll notice that static/static.go is a generated file as part of the build process. Such file is usually not committed to the repo so you'll need to build it yourself. To do so, you'll need to have go-bindata installed.
Here's what you need to do in order to build the project successfully:
Get the go-bindata package
go get -u github.com/jteeuwen/go-bindata/...
Get the project
go get github.com/evq/chromaticity
Go the project root directory
cd [...the chromaticity project root..]
Run make to generate the static/static.go file
make
Build/ install the project
go install
Update:
Noticed from your screenshot that you're using Windows, in that case you may need to workaround the issue of running Makefile in Windows. See here for possible solution: How to run a makefile in Windows?
I've run into the same issue when trying to "get" and then install this project. I looked into the code and there is no trace of Asset() function in github.com/evq/chromaticity/static. Moreover git history does not show any .go files in static/ directory. Personally, I would create issue in the project and/or look for different repo containing desired functionality.
I have a weird issue with golang. I run the command (like everytime):
go run main.go
Then I made some change into my code and then I run again:
go run main.go
But the executed code is the old version of the code. So I tried some stuff:
Reboot the computer
Delete all the temporary binaries into temp folder
Reinstall go
Delete and put back my code
Remove some file
But it is still running my old version of the code. I didn't find solution about this issue, and the few post about it doesn't give a solution (here and here).
About my configuration it is the following:
Raspberry pi running Raspbian (updated)
Go version 1.8.1
I hope you can help me !
Thank in advance!
Best regards,
Okay!
The problem come from the imports. In the code some imports was calling old version of the code.
I think your GOPATH is pointing to a wrong folder. Please, run go env to make sure that it is pointing to the right directory. If not set it to location where go files are. Please, take into account that go run usually does not need a file specification and if you do you have to list defacto all files of your app that main.go depends upon.
Have a look ``here
First I have read this answer: Vendoring in Go 1.6, then I use it as my example.
My gopath is GOPATH="/Users/thinkerou/xyz/", and the follow like:
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ pwd
/Users/baidu/xyz/src/ou
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ ls
main.go vendor
Now, I use go get, then becomes this:
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ ls
main.go vendor
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou$ cd vendor/
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ ls
vendor.json
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ cd ../..
thinkerou#MacBook-Pro-thinkerou:~/xyz/src$ ls
github.com ou
thinkerou#MacBook-Pro-thinkerou:~/xyz/src$ cd github.com/
thinkerou#MacBook-Pro-thinkerou:~/xyz/src/github.com$ ls
zenazn
vendor.json is this:
{
"comment": "",
"package": [
{
"path": "github.com/zenazn/goji"
}
]
}
then, I should use what commands? why have no use vendor? My go version is 1.6.2.
With Go1.6, vendoring is built in as you read. What does this mean? Only one thing to keep in mind:
When using the go tools such as go build or go run, they first check to see if the dependencies are located in ./vendor/. If so, use it. If not, revert to the $GOPATH/src/ directory.
The actual "lookup paths" in Go 1.6 are, in order:
./vendor/github.com/zenazn/goji
$GOPATH/src/github.com/zenazn/goji
$GOROOT/src/github.com/zenazn/goji
With that said, go get will continue to install into you $GOPATH/src; and, go install will install into $GOPATH/bin for binaries or $GOPATH/pkg for package caching.
So, how do I use ./vendor?!?!
Hehe, armed with the knowledge above, it's pretty simple:
mkdir -p $GOPATH/src/ou/vendor/github.com/zenazn/goji
cp -r $GOPATH/src/github.com/zenazn/goji/ $GOPATH/src/ou/vendor/github.com/zenazn/goji
In short, to use vendoring, you copy the files using the same github.com/zenazn/goji full path, into your vendor director.
Now, the go build/install/run tooling will see and use your vendor folder.
An easier way instead of copying everything manually
Instead of finding and copying all 25+ vendor items, managing their versions, updating other projects etc... It would be better to use a dependency management tool. There are many out there and a little googling will point to you several.
Let me mention two that works with the vendor folder and doesn't fight you:
godep
govendor
In short, these tools will inspect your ou code, find the remote dependencies, and copy them from your $GOPATH/src to your $GOPATH/src/ou/vendor directory (actually, whatever current directory you are in when you run them).
For example, say you have all of your dependencies installed and working normally in your $GOPATH/src/ou/ project using the normal GOPATH/src/github installation of your dependencies. Your project runs and your tests validate everything is working with the exact version of the repos you have. With Godep as an example, you'd run this from your project root folder $GOPATH/src/ou/:
godep save ./...
This would copy all dependencies your project uses into your ./vendor folder.
Godep is by far and large the most popular. They have their own Slack channel on the Gopher Slack group. And, it's the one I use on my teams.
Govendor is another alternative I read has a nice sync feature. I haven't used it though.
Over Usage of Dependency Management Tool
This is purely opinion, and I'm sure haters will downvote... But as I need to finish my blog post on the subject, let me mention here that most people worry too much about depdency management in Go.
Yes, there is a need to lock in a repo to a version you depend on so you can ensure your system builds in production. Yes there is a need to ensure no breaking changes to a way a dependency is interrupting something.
Use dependency management for those, absolutely.
But, there is overuse of simple projects that lock in huge amounts of dependencies when in reality...
You may only need to lock in only 1 dependencies; otherwise, you want the latest version of MySQL drivers and test assertion frameworks for bug fixes.
This is where using the ./vendor/ folder apart from dependency managrment tools can really shine: you'd only need to copy that repo that need you lock in.
You selectively pick the one misbehaving repo and put it into your ./vendor/ folder. By doing this, you are telling your consumers:
Hey, this one repo needs to be held back at this revision. All others are fine and use the latest of those and update often with go get -u ./...; but, this one failed with newer versions so don't upgrade this one repo.
But if blanketly saving all your dependencies with a dependency management tool, you are basically telling your consumers:
There may or may not be a problem with one or more repos out of the 20 in the vendor folder. You may or may not be able to update them. You may or may not be able to get the latest MySQL driver. We simply don't know which may or may not be causing problems and just locked in something that worked at the time that I ran godep save. So yeah, upgrade at your own risk.
Personally, I have ran into this several times. A dependency was updated with a breaking change, and we have dozens of repos dependent on it. Vendoring just that one repo in /vendor allows us to use that one version of dependency, while go get ./... continues to run normally for all other repos to get the latest. We run with the latest bug fixes in PSQL and MySQL and others (there are constant fixes for these!) and so on.