Hacker News Reader

Comment by ubercow | Hacker News Reader

I love Go for the concurrency and awesome cross platform support, but my biggest complaint about Go is still the forced GOPATH.

I know this is super nitpicky, but I like to keep work and personal code completely separate and changing GOPATHs is very frustrating.

With the introduction of `vendor` and software like glide and dep tool, you no longer have to store your sources in `$GOPATH/src`.

Since dep/glide are also required for sane dependency version management, there seems to be no benefit of using `src` over `vendor`.

Without `src`, is there any reason `GOPATH` is still required?

View on HN

I second this, please remove the forced GOPATH with the upcoming Go 2.0. (GOPATH is annoying to handle with multiple repositories in different paths, and probably there is no reason to have it anymore anyway.)

I really like Go, it's so nice for server side applications.

How frustrating is it to change GOPATH? In each GOPATH, create a file called "source" or something, and put the following in it:

  export GOPATH=/home/ubercow/project2/

Or even:

  export GOPATH=`pwd`

When it's time to work on your project just say

  . source

This seems like an INCREDIBLY minor step to take. It's certainly no worse than using pyenv.

If you're that fussed about it why not go build -i inside your personal repo ?

Or have a GOPATH with two dirs like:

    GOPATH="~/workgo:~/homego"

Completely separate = dont allow dependencies between or one is base and second auguments and depends on base or dont allow changes to one of them?

How would your ideal system look like? What is your use case?

Sidenote if it helps there is a default gopath location if its not defined: https://golang.org/doc/go1.8#gopath

My ideal system is: clone a repo, run `go restore` to fetch dependencies and then `go build` to spit out a binary or `go run` to quickly start the main function.

Nothing from outside the repo can effect that build. Likewise anything inside the repo can’t effect the outside.

Compartmentalizing each project makes builds more reproducible and more obvious. If anyone else clones the same repo and runs the same commands, they should get the same result.

We actually do this at work; our repository is a full GOPATH layout with subdirectories for src/, test/, doc/, etc. We vendor our dependencies. To build, we have scripts at the top-level that compile all of our components (we ship a whole suite of tools in a single repo), run go vet, run tests, etc. The user never needs to set GOPATH. It's not a perfect system, but we've been using it for 3+ years without too much trouble.

I’m trying to not rely on GOPATH too, but how do you import sub packages? Are you supposed to put them in vendor too?

Vendoring is based on the VCS, so it vendors all packages (and "sub-packages") at once.

Reply on news.ycombinator.com