I am using windows 10.
In this link is it been asked to remove current Go installation before updating to new version. The current installation folder is something like: C:\Go . And it is been asked to remove this folder first before installing the latest version.
But I already have my projects under C:\Go\src. So I can't afford to delete it just like that. Not sure what I am missing. I have never updated Go before, so this is new to me. Thanks.
Those same instructions tell you to...
Create your workspace directory, %USERPROFILE%\go. (If you'd like to use a different directory, you will need to set the GOPATH environment variable.)
C:> cd %USERPROFILE%\go\src\hello
C:\Users\Gopher\go\src\hello> go build
So your src directory should not be in C:\Go\src but %USERPROFILE%\go\src\ (that is in your home directory). If you've been using C:\Go\src, move it to %USERPROFILE%\go\src\ and use that going forward.
Related
Go seems to create a folder ~/go with a folder pkg/mod inside. Deleting this folder simply leads to it being recreated as Go is run in due course.
Does anyone know how to set the Go environment such that this folder resides elsewhere? My go env shows the following line for $GOCACHE & $GOMODCACHE:
...
GOCACHE="~/Library/Caches/go-build"
GOMODCACHE="~/Library/gocode/pkg/mod"
...
(I've replaced the /User/<user name>/ bit here with ~/.)
There's no sign of the ~/go folder in either of them, so I'm lost as to how to redirect it.
I have Go version go version go1.19.5 darwin/arm64 on macOS Ventura.
The go clean -i command that is ran inside some project deletes an executable file of that particular project that was previously installed by go install command. How to delete everything installed by the go install commands that were ran from several different projects? Is there some single go command that can do that?
TL;DR
Delete the binary like any other file.
The "install" term means place (something) in a new position ready for use.
Therefore, Go builds a single-file binary and places it in another directory ($GOPATH/bin). It is useful when you add the Go binary directory into the environment variable to call the program.
There's no auxiliary flag such as go clean -bincache to remove all binaries installed by Go 1.16.4.
However, at the current version of GoLang (1.16.4), the right way to remove (or "uninstall" as you said) any installed binary is solely to delete it, like any other file despite you feel it sounds awkward.
I have installed go package. When I go to the instance(VM) and run the command
go get github.com/linkedin/Burrow from a terminal/cmd it is downloading both "src" & "bin" folder under user home directory. But when I run the same command by setting GOPATH in a shell script, it is only downloading the "src" folder but not generating "bin" folder.
SOURCE_DIR="/opt/burrow"
export GOPATH=$SOURCE_DIR/go
go get $BURROW_REPO
Am I missing anything?
Use go install command (Compile and install packages and dependencies).
That command download src to $GOPATH and build it to $GOBIN.
GOBIN may not be set at the moment.
You can check by go env GOBIN. if its empty so you must set with export GOBIN=$(go env GOPATH)/bin
Also, for calling binary files from your terminal, you need to use go install command. This will create related bin file under GOBIN path.
There's a lot going on here.
The first point of your confusion is that go get does not download neither "src" nor "bin": Go packages are always contain only source code, and they typically does not contain the "src" directory in their file and directory hierarchies.
Instead, these directories are artefacts of the the Go toolchain.
The second point of confusion is that since Go 1.8, the Go toolchain uses a fallback value for the GOPATH environment variable if that is not set, and on Unix-like systems it defaults to the directory named "go" under the "home" directory of the user executing the go command.
If this directory is missing, the toolchain will create it.
Hence my stab at your problem is that you have some sort of permissions problem: when GOPATH is unset, "$HOME/go" is used — with whatever value $HOME expands to for the current user; when you set GOPATH by hand, something prevents creation of the "bin" directory under $GOPATH.
There's another possibility: you also set the GOBIN environment variable, which, when set, overrides the usual location used to install binaries built by go install (and go get).
You might study the output of go help environment to read more on the subject.
In either case, the most sensible path forward is to run go install with the -x command-line option and see where the command tries to put the generated executable image, and why this fails (if at all).
You might study the output of go help install and go help build to read more on the subject.
You might also consider forcing usage of Go modules for your particular case:
running GO111MODULES=on go get github.com/linkedin/Burrow would work like five times faster for your use case.
Be sure to study the output of go help modules and go help mod-get first.
bin folder or src folders are not automatically created for you by the go get command. Here are the standard steps creating a new project in go assuming this the first time you are creating a project in go:
Under your workspace directory, create a project directory, say "project1" bin, src directories.
Set GOPATH, GOBIN:
export GOPATH=~/workspace/project1/
export GOBIN=~/workspace/project1/bin
Now if you need just the source code, do a go get github.com/linkedin/Burrow
or if you need a binary do a go install github.com/linkedin/Burrow
The binary will be stored under ~/workspace/project1/bin and source code under ~/workspace/project1/
Same steps would apply either if your creating your project through a make file or terminal
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 am new to Go programming language and every tutorial starts off from setting GOPATH to current project folder.
Am I missing something? Is programmer really supposed to set GOPATH manually when he cd to his new Go project folder? I have read several FAQ entries about GOPATH but still couldn't wrap my head around it.
And why does GOROOT exist then? What's its purpose?
Are there any automatic tools which detects if current directory is root folder of Go project (for example by some hidden file) and changes GOPATH to this directory automatically?
Thank you, any advice really appriciated
ps. For example I develop completely disjoint Go projects A, B and C, should they live in single "workspace" environment? I guess not, but what I should do with GOPATH and GOROOT then?
The goal of the GOPATH is to centralize all packages into one common workspace. It is not really a new concept by itself (think of the Java Classpath for example), but Go's use is drastically simpler by not supporting packages versioning.
The Go programmer isn't supposed to set GOPATH manually when entering a new project folder. Each project folder is supposed to be a package by itself, and reside in the GOPATH along other packages, so GOPATH should be set only once. Tutorials begin by setting the GOPATH in order to isolate the tutorial workspace from anything else (or simply assuming that a user hasn't set the GOPATH, yet).
GOROOT is set to provide the standard packages to the Go programmer, you don't need to do anything with it. In short, there is a single rule for GOROOT: never, ever, touch it. Don't install anything in it, don't modify standard packages, etc.
I'm not aware of a tool to detect Go projects in the current directory, but it shouldn't be highly complex to create.
How you handle different projects is up to you. The Go way is to put every project as a package in the $GOPATH/src directory and do everything from there. As I don't really like it, I defined my GOPATH to be $HOME/.go. Then I put each project in a dedicated directory somewhere else (anywhere in my computer), and symlink the project directory into my $GOPATH/src dir. I can then use every Go toolchain command (e.g. go build myproject), use the project as package for another one, etc.
GOPATH allows you to collect dependency source code and the resulting compiled binaries in one place. This seems like a really attractive idea. However, I found myself working on several totally unrelated Go projects and an alternative approach suited me better.
This is a similar but different strategy to Elwinar's symlnks. I start a new project in an empty folder and create src. And I drop into the folder this shell script called env.sh:
if [ `type -p go` = "" ]; then
export PATH=$PATH:/usr/local/go/bin
fi
export GOPATH=$PWD
export PATH=$PATH:$PWD/bin
Each time I start work, I use
. env.sh
Note the dot and space - they matter.
Now, everything I do on this project is localised within this folder. It's possibly not the most widely-used strategy, but it works well for me.
And another thing: if your dependencies make use of environment variables for testing etc, you can put them in env.sh too. For example, Gorp has
export GORP_TEST_DSN=test/testuser/TestPasswd9
export GO_TEST_DSN=testuser:TestPasswd9#/test
Addendum
In the most recent Go versions, GOPATH is optional; if you don't set it, the default is $HOME/go. If you do set it and also want to use the new modules feature, set GO111MODULES=on also.
You don't need to set your GOPATH or GOROOT. GOPATH by default is under your user/home directory.
If no GOPATH is set, it is assumed to be $HOME/go on Unix systems and %USERPROFILE%\go on Windows. If you want to use a custom location as your workspace, you can set the GOPATH environment variable.
Go Modules
Now there's Go Modules support (since Go 1.11), so you don't have to use GOPATH anymore. For example, you can go to any directory on your system (outside of $GOPATH), and you can initialize a new Go module there, then you start working there. No GOPATH is needed.
You just need to do this once (while in a directory):
go mod init
$GOPATH: Go stores these files under it:
Source files ($GOPATH/src)
Compiled package files ($GOPATH/pkg)
Runnable files ($GOPATH/bin)
$GOROOT: Where the Go source code resides like Go Standard Library.
Also to run any go installed executable file from anywhere on your system, you might want to add $GOPATH/bin to your path environment variable like this:
export PATH=$PATH:$(go env GOPATH)/bin
More information check out this.