My git projects are stored here:
~/dev/git/project1 ...
I am starting a golang project, and since it requires using the GOPATH is it common practise to create a symbolic link from my projects git path to GOPATH?
A symbolic link, also known as a soft link or symlink, is a special file pointing to another file or directory using an absolute or relative path. Symbolic links are similar to shortcuts in Windows and are useful when you need quick access to files or folders with long paths.
A symbolic link creates a file in your directory and acts as a shortcut to a file or folder. For example: I have a directory- let's say example.com. However, I want a shortcut to another directory within the example.com. To do this, you would create a symbolic link.
A symbolic link points to a file. In case, the original file is deleted, the symbolic link would be pointing to non-existing file. You can create a symbolic link to a directory too.
ls command to find a symbolic link in UNIX systems If you combine the output of the ls command with grep and use a regular expression to find all entries which start with a small L then you can easily find all soft links on any directories.
Because of dependency issues between packages, symlinking was used for the GOPATH. The structure of GOPATH, however, always suggested that it was to be used for multiple projects and symlinking your GOPATH
has been discouraged by the go developers.
In the latest version (1.6), however, they finalised a solution to the dependency problem (experimentally introduced in 1.5), in the form of a folder named vendor/
placed at top level of your package (link). This folder will be searched before the regular GOPATH
for package used by import statement.
There are various tools to use to streamline the dependency process like godep or glide, making using the vendor/
folder a lot less time-consuming than symlinking the GOPATH
. Using a vendor package is also better reproducible than symlinked dependencies, ensuring your package will work for everyone.
So I would encourage you not to symlink your GOPATH, and use this newly introduced standard.
What I end up doing is instead created my own GOPATH
within a go project I want to keep isolated to my normal global $GOPATH
.
I make a 'b
' script (at the root folder of the project) which:
src
exists (in the project folder, here in ~/dev/git/project1
): if not it creates it;src/mypackage -> ~/dev/git/project1
. alias b='. ./b'
That way, the same 'b
' (short for 'build') goes into ~/dev/git/project1/src/mypackage
, and does a go install
.
If you have a main
package, that will create a binary in ~/dev/git/project1/bin
.
That way, each of my go project remains autonomous, not lost in a sea of other go packages in my normal $GOPATH/src
. I reserve the global $GOPATH
for global projects that helps me to develop in go: golang.org/x/tools/cmd/...
, github.com/fzipp/gocyclo
and the likes (other linters).
In other words, I do not symlink GOPATH
.
I do symlink my package inside my project to a local GOPATH
(local to said project), but the GOPATH itself is a fixed folder (again specific to my project), defined as usual, without any symlink)
And that is perfectly compatible with the vendor folder for vendoring source dependencies.
alias b='. ./b'
cd /path/to/my/project
b:
#!/bin/sh
if [ ! -e src ]; then mkdir src ; fi
if [ ! -e src/myproject ]; then ln -s /path/to/my/project src/myproject; fi
cd src/myproject
go install
cd ../..
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With