4 ms·

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,

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?

hgl 9y ago
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?
- infogulch 9y ago
  Vendoring is based on the VCS, so it vendors all packages (and "sub-packages") at once.
zenlikethat 9y ago
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"
DelightOne 9y ago
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 https://golang.org/doc/go1.8#gopath
- ubercow 9y ago
  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.
  - jff 9y ago
    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.
frik 9y ago
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.
jff 9y ago
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.

hgl 9y ago

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?

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

zenlikethat 9y ago

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"

DelightOne 9y ago

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 https://golang.org/doc/go1.8#gopath

ubercow 9y ago
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.
- jff 9y ago
  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.

frik 9y ago

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.

jff 9y ago

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.