CODEWITHSUNDEEP
gitgo
cool breeze
cool breeze

Reputation: 4811

Is it common practice to symbolic link to the GOPATH folder?

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?

Upvotes: 8

Views: 7439

Answers (2)

VonC
VonC

Reputation: 1324757

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:

  • check if src exists (in the project folder, here in ~/dev/git/project1): if not it creates it;
  • check if src/mypackage exists: if not, if creates the symbolic link src/mypackage -> ~/dev/git/project1.
  • is called with an alias: 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 ../..

Upvotes: 1

Dekker1
Dekker1

Reputation: 5786

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.

Upvotes: 3

Related Questions