Monday, March 24, 2014

Use a Single GOPATH in Go (GoLang)

I like when things can be neat and modular. It makes sense in my world. I like the idea that if something gets mucked up, it's easy to pull the "nuclear options" and just delete that bit and start over. It's part of the reason I like the Mac; most of the time when you want to delete an application, you just delete the .app bundle (there might be some preference files to delete, but for the most part, this isn't an issue.)

Go, by default, likes creating static binaries. Sure, it may wreak a little hell on memory use, but when it's a static binary, you just copy the binary and it works. No dependencies to fuzz over or accidentally break.

So this philosophy extends to projects I'm working on. While playing with programming, I like to create separate work directories, so when I inevitably screw up I can delete it (if need be) and start over. Plus it kind of sandboxes my work, so I don't spread the muck among my learning endeavors.

Guess what? That's not the Go Way.

(Has anyone really worked on documenting the philosophy of Go? I mean, Ruby has the whole Rubyist way of doing everything; reading tutorials and blog posts about the language from people who aren't bitching about it would make you think the language is half programming language and half poetry, complete with a set of unwritten-but-documented rules that are half documentation and half teachings of a programming philosopher. But I digress...)

I wasn't completely aware of the Go Way until I talked to a coworker who is a fan of Go and I had an issue I posted about on StackOverflow. He sent me an email with a link to a blog post called "Why I use just one GOPATH." It helped clarify some thinking for me.

After reading the documentation on workspaces, I started creating a directory per project, each with its' own src, pkg and bin directory. Then I pointed my GOPATH to that folder. This was what I thought the instructions said, and there wasn't anything that explicitly said not to do that. I was simply exporting GOPATH at the prompt when I needed to.

Don't do that.

You could do it that way, but it's a bit more of a pain and isn't the Go way. What Go wants you to do is to put your projects into their own subdirectories under /src. For example,

/home/myuser/goprojects
                       /src
                           /project 1
                           /project 2
                           /project 3
                       /bin
                       /pkg

Each project will go into the appropriate folder under src, executable binaries end up in /bin, and you get one GOPATH set to /home/myuser/goprojects.

While it still grates my own aesthetic tastes to somewhat mingle all the projects into one folder, it does simplify my Git repository and still somewhat sandboxes my application experimentation by keeping source code in just the /src. 

So if you, like me, found the online documentation for Go to be vague enough that you find a way to make it fit your workflow rather than understanding the Go Way(tm), you're probably doing it wrong. Create one folder path, set it to GOPATH, and create new applications as subfolders under $GOPATH/src.

No comments:

Post a Comment