$GOPATH or $GO111MODULE

Technical Discussion
1

as beginner, I’d like to know what’s the best practice to go with $GOPATH or $GO111MODULE. Does go get require $GOPATH set up so it will download all dependencies to $GOPATH directory?

Thanks

1 Like
2

If you use newer Go verison, let´s say the latest, forget about this. Use modules.

1 Like
3

I am using latest verison, and get my GO111MODULE=on set up. My follow-up question is the go get still requires $GOPATH setup? I tried go get and looks like it download packages under directory as configured by $GOPATH.

1 Like
4

  1. Yes, go get still requires GOPATH.

  2. You still need to setup GOPATH not for the reason of development but rather maintaining the go get binary distribution mechanism. Example to install golangci-lint go program, we still use:

$ go get -u github.com/golangci/golangci-lint/cmd/golangci-lint
  1. However, moving forward, your development should stick to module (with a go.mod file) instead. That also means you rarely use go get except getting some go program installed out-of-the-box like (#2).
1 Like
5

Thanks @hollowaykeanho. some follow up quesitons.

  1. if we use go get to download an out-of-the-box program as in your example to GOPATH directory, when we need this program, will GO automatically search it in GOROOT as well as GOPATH?

  2. I think we can also use go get to download packages or dependencies for our projects, since we’re using GO111MODULE which typically don’t use GOPATH directory, how GO know where to find these downloaded dependencies for our projects? Does GO also automatically search GOPATH for any dependencies that we use for our project (which I don’t believe so)?

  3. go get -u, -u here per my understanding means update which will send your local update to the github (for this example). Do we need -u if we don’t have any plan to update the github? I see folks use -u most likely so just try to clarify a bit here

2 Likes
6

When you need to use the Go program like the given example, which is a powerful linter to check your go source codes. It will automatically search in GOPATH. Any compiled binary is stored under GOBIN, which is essentinally GOPATH/bin.

Module uses a different mechanism to organize the dependency. As far as I understand, it is no longer using GOPATH (that was the goal). Module highly depends on go.mod file’s require clauses to provide the list of dependencies. For more info, I suggest you spend some times to read through these documentations and do a deep dive experimentation with some dummy repos:

1.Modules · golang/go Wiki · GitHub
2. Using Go Modules - The Go Programming Language

P/s: I’m still waiting for the instruction from the developers to finally let go of GOPATH. As of to-date, I’m still having binary installations in my GOPATH.

-u argument put it simply, is to pull the latest from Github to your local repository and re-compile the corresponding binary (if any). It is not the other way round. Hence, the name update, which stands for “update your local repo”.

To push from local repository to Github, you develop using your conventional way which is enter into the directory and git push. (Can you feel our pain before go module, in the past just by reading that sentence? :rofl:)

1 Like
7

Even now I feel more pain not only these sentences but more the confusion between GOPATH and GO111MODULE:rofl:

Does go get not only download the program but also do the compiling and put complied binary into $GOPATH/bin as well?

since now I am using IDE goland and I assume these go tools (can I view golangci-lint as one of go tools) are automatically taken care of by IDE, it’s even rare to use go get. agree?

2 Likes
8

Yes, automatically. You get the source codes in GOPATH/src and binary in GOPATH/bin.

Beats me on go getting tools for programming Go. That depends on the IDE robustness. I can’t answer deeply on IDE part because I’m one of the outdated Linux vi guy that still producing 80 max columns codes :zipper_mouth_face:.

Nope. You still need to familiarize with go get. It is just an easy, basic, and another way to distribute go program (those that has main codes, like the very useful Hugo). You still need it for cases like:

  1. developing any CI or infrastructure tool. Exception to using official installers / cheat your way up with docker images.
  2. survive strict and outdated system (like my stable branch Debian), this type of channel is important since a lot of native software packages are outdated.
  3. quickly download the latest version of go program without all the yada-yada packaging drama like pay annual membership fees of USD125 / USD25 and sign agreements as thick as my car bumper.
  4. your last resort of distributing your Go program.

Tl.DR (4D):

  1. Do set the GOPATH and go with the flow
  2. Develop using module; download program using go get
  3. Doubt? feel free to ask again
  4. Don’t stress yourself up; Relax, have a cup of green tea.

Go is a very powerful tool. Let time nourish you. Welcome aboard, gopher! :rocket::fireworks:

1 Like
9

You mentioned there is possibility to retire GOPATH but looks like at least it’s needed for go get working probably, so I assume there will be other way for go get once we let it go of GOPATH?

Thanks and your remarks are very inspiring!

2 Likes
10

I strongly believe the go get command remain as the same for backward compatibility. Even in go1.13, it was upgraded instead of being replaced.

I’m expecting only the underlying GOPATH mechanism will change. That will take some times because not everyone is onto module yet and it is not an easy task to make such transition.

Don’t worry. When it is time to drop GOPATH, it will be a huge announcement.

1 Like
11

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