Why do we need a gopath?


(Erwan Roussel) #1

I don’t understand why do we need a gopath ?
That’s extremely nervous for me…
I can’t work on Golang project without to be in this gopath…


(Lutz Horn) #2

Is there any reason why you want your project to not be in GOPATH?


(Grzegorz Żur) #3

You can switch to vgo. It manages dependencies without GOPATH.

https://research.swtch.com/vgo


(Erwan Roussel) #4

Thx I’ll take a look at it :wink:


(Erwan Roussel) #5

I have the same repo for the angular app and the server and I don’t want to put angular files in my gopath …


(Tim Heckman) #6

@dimensi0n It took me a little bit, as a new gopher, to really get and appreciate the GOPATH. Now that I’ve been working with it for a few years, I find it to absolutely be one of the best features of the language.

It gives me a consistent location for storing my source code, as well as for finding the source code I depend on. Because I use GitHub, I know for a fact that all of my Go code will be under $GOPATH/src/github.com/theckman. If I am forking a project to make some changes to it I can create the fork in my GOPATH, using the original name, and can then use it from my project with my modifications. It also gives me a prescriptive location to put code that I contribute to.

It’s also the path where dependencies are found, and because we use the canonical name for our imports (github.com/theckman/example), your GOPATH needs to ensure your code is in that location ($GOPATH/src/github.com/theckman/example). I think this makes things super consistent and easier to reason about, in comparison to other languages that largely rely on relative imports. This also means that if you want to bundle JavaScript, or other artifacts in the repo, they need to live in the same location. You could develop the frontend UI and backend API in separate repos.

I’d say give the GOPATH a real try, and have an open mind. If you treat it as the canonical location for where all of your Go projects are going to live, it’ll make things more clear in the long-run and you’ll be working in a way that’s consistent with the Go community. Keeping yourself aligned with the community means you have more resources available to you as you learn the language.

:100: on the GOPATH.


(Jakob Borg) #7

I find GOPATH really annoying in that it makes setup in random build servers cumbersome and confuses newbies every day. But it is single handedly responsible for me cleaning up my source organization from my old “system” of essentially ~/projects/whatever/junk-v2 that had no connection to any reality into ~/src/github.com/calmh/myproject where I now know exactly what everything is and where it is pushed to.

Now that I’ve straightened that out I’ll be very happy to see it go away again with vgo.

More practically speaking, given the above source organization, having Angular, Python or Ruby code in there among the Go stuff is perfectly fine. I wouldn’t worry about it.


(Julien Heger) #8

Just a random thought:
I had a Go project that, because it is part of a bigger project, I wanted to put in the proper place inside the bigger project (which obviously isn’t in the GOPATH), just for my own sanity really.
What I ended up with is creating the project normally under the GOPATH and then from the “bigger project” I hardlinked against that folder.
Might not be the proper way to do it, but worked for me; even all dev tools play nice with it.


(Erwan Roussel) #9

Thx for all replies I understand know the importance of GOPATH


(system) #10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.