Thinking about $GOPATH

This is a creation in Article, where the information may have evolved or changed.

This was a short blog post about my thoughts on using Go in anger through several workplaces, as a developer and an Advocat E.

What is $GOPATH?

Back when GO is first announced we used Makefile s to compile go code. These Makefile s referenced some shared logic stored in the Go distribution. This is the where $GOROOT comes from.

Back then, if you wrote Go code, you ' d probably also used these Makefile s, and while your could check out your source code any Where, most people would put their own go code in what today we ' d call as you $GOROOT/src must ' ve compiled Go from source, so th Is directory are always going to be present.

Towards The 1.0 release then solidified the use of goinstall, go get, domain names in import paths to provide a globally unique n Amespace. These tools introduced a new location to which Go code would be fetched. This is separate from $GOROOT to make clear the distinction between code provided by the Go project, and code writ Ten by the developer. By the time Go 1.1 is released in, is $GOROOT removed as a fallback option.

Why does $GOPATH exist?

$GOPATHexists for the main reasons:

1. In Go, the import declaration references a package via its fully qualified import path. $GOPATH Ory inside the $GOPATH/src go tool can compute the absolute import path of the package in Question.1
2. A location to store dependencies fetched bygo get.

Have a per user $ GOPATH environment variable also means developers could use the Go tool from all directory on T Heir system to build, test and install code, but I suspect only a minority utilise this feature.

What ' s wrong with $GOPATH?

In my experience, many newcomers to Go is frustrated with the single workspace $GOPATH model. They is confused that $GOPATH doesn ' t let them check out the source of a project in a directory of their choice like they a Re used to and other languages. Additionally, does not let the developer has more $GOPATH than one copy of a project (or it dependencies) checked out at The same time without has to update $ GOPATH constantly.

I think it is important to recognise that these issues be legitimate points of confusion for many newcomers (including th OSE on the Go Team) and act as a drag on go adoption. As we ' re on the cusp of a blessed dependency management tool for Go, I think it's equally important to continue to questio n the base assumptions that this new tool would build on, namely requiring a $GOPATH .

In my opinion, any Go build tool needs to provide (in addition to actually building and testing code) A-to-go code CH Ecked out in a arbitrary location on disk to recover its intended fully qualified import path; The path other code would import it as.

The model answers this question by subtracting the prefix of the the directory of the $GOPATH $GOPATH/src Kage; The remainder is the package ' s fully qualified import path. If you check out a package outside a $GOPATH workspace, the Go tool cannot figure out the packages ' fully qualif IED import path and everything falls apart.

What is some alternatives to $GOPATH?

I attempted to address both issues gb with, which gives developers the ability to check out a project anywhere you want , but have no solution for libraries, and GB projects were not go gettable. However GB showed that writing a new build tool that does not wrap the go tool meant it is not forced to reorganise the Wo Rld to fit into the $GOPATH model allowing GB users to include the source of any their dependencies in their project without The pitfalls of the Go 1.6 ' s vendor/ directory.

Recently, on a suggestion from Bill Kennedy, I built an experimental build tool that recorded the expected import prefix I n a manifest file. That's prefix, rather than one computed by $GOPATH directory arithmetic, was used to determine the fully qualified import path.

I ' m working on a similar tool (unfinished) based on a suggestion from Brad Fitzpatrick that uses the .git directory as a Sentinel to determine the root of the project and hopefully infer the full import path from the git remote configuration.

While these experiments is unfinished, both demonstrate that can avoid the $GOPATH restrictions and retain compatibilit Y with the go get ecosystem. Potentially in the case of Kodos, even avoid a manifest file.

Conclusion

Kang and Kodos Use a IoT of forked code from GB, which I hope to rectify over the New Years ' break. If you is interesting in contributing or better yet, building your own Go tool to explore this problem space, Kang, Kodos , and GB are permissively licensed.

Notes:

1. This was notably different from the the-the-the-the-scripting languages like Python and Ruby, which use directly Scanni Ng and inserting onto a global search path source code directories.

Related Posts:

1. You don ' t need to set goroot, really
2. How to install multiple versions of Go
3. Five suggestions for setting up a Go project
4. Test Fixtures in Go