3 ms·

I looked at Go a couple years ago now and haven't gone back for a bit because I could never wrap my mind around how to get started. Every Go developer I know ju

by bphogan 11y ago

I looked at Go a couple years ago now and haven't gone back for a bit because I could never wrap my mind around how to get started. Every Go developer I know just replied with "It's easy. Duh. Just read Effective Go." So, I'll ask here. 1. What's the deal with GOPATH? 2. How do I structure my projects? 3. I would like to make command line tools that run on many platforms. Where do I get started?

sagichmal 11y ago
1. `export GOPATH=$HOME` -- or, `export GOPATH=$HOME/go` if you insist. [0] 2. a. All of your Go source MUST exist somewhere underneath $GOPATH/src. Otherwise, the build tooling simply won't work. [1] 2. b. If your Go project is hosted on e.g. GitHub, it needs to exist at the path $GOPATH/src/github.com/bphogan/reponame. Do not attempt to work around this convention. [2] 2. c. Finally, whenever you import a package -- even if it's a subdirectory of the same project/repo that you're working in -- you need to specify the complete import path. That is, import "github.com/bphogan/reponame/mypkg". [3] This has implications for forks, which can be dealt with. 3. a. Create a new repo on GitHub, write a `package main`, and commit/push. Now, anyone with a working Go installation can `go get github.com/bphogan/reponame` and your commandline tool will be downloaded, compiled, and placed in $GOPATH/bin for them to use. 3. b. As of Go 1.5, you can cross-compile binaries for platforms other than your own, by setting the GOOS and GOARCH environment variables before the `go` command. For example, if `go build` produces a binary for your current OS/Arch, then `env GOOS=linux GOARCH=amd64 go build` will produce a binary for linux/amd64. --- [0] In reality, GOPATH is actually like PATH in that it can contain multiple delim-separated paths. This has consequences that you need to think through. https://golang.org/cmd/go/#hdr-GOPATH_environment_variable https://golang.org/cmd/go/#hdr-GOPATH_environment_variable [1] For the most part. `go run` works anywhere, for example, but you shouldn't be using that as part of your regular dev cycle. You can also compile and link manually, if you really want to. [2] Strictly speaking, you can get around this requirement, with a latticework of clever tricks and hacks. Some people like to have their repos represent their own GOPATH, and play games with setting a new GOPATH for each new repo/project. I can almost guarantee you that if you start doing this, you will become very frustrated with the language and probably give up on it. [3] Relative imports, like import "./foo", are technically allowed by the compiler, but are widely considered to be a mistake outside of one very specific circumstance having to do with test packages.
- snikch 11y ago
  Quick note on 3.b - Go 1.5 didn't introduce cross compilation, that's been around for much longer.
  - sagichmal 11y ago
    Yes, but before Go 1.5 you had to build the toolchain for each target manually, and with Go 1.5 it comes by default.
- bphogan 11y ago
  Thank you kindly for this concise and well explained answer. I truly appreciate the time you took with your explanations.

by bphogan 11y ago

sagichmal 11y ago

1. `export GOPATH=$HOME` -- or, `export GOPATH=$HOME/go` if you insist. [0] 2. a. All of your Go source MUST exist somewhere underneath $GOPATH/src. Otherwise, the build tooling simply won't work. [1] 2. b. If your Go project is hosted on e.g. GitHub, it needs to exist at the path $GOPATH/src/github.com/bphogan/reponame. Do not attempt to work around this convention. [2] 2. c. Finally, whenever you import a package -- even if it's a subdirectory of the same project/repo that you're working in -- you need to specify the complete import path. That is, import "github.com/bphogan/reponame/mypkg". [3] This has implications for forks, which can be dealt with. 3. a. Create a new repo on GitHub, write a `package main`, and commit/push. Now, anyone with a working Go installation can `go get github.com/bphogan/reponame` and your commandline tool will be downloaded, compiled, and placed in $GOPATH/bin for them to use. 3. b. As of Go 1.5, you can cross-compile binaries for platforms other than your own, by setting the GOOS and GOARCH environment variables before the `go` command. For example, if `go build` produces a binary for your current OS/Arch, then `env GOOS=linux GOARCH=amd64 go build` will produce a binary for linux/amd64. --- [0] In reality, GOPATH is actually like PATH in that it can contain multiple delim-separated paths. This has consequences that you need to think through. https://golang.org/cmd/go/#hdr-GOPATH_environment_variable https://golang.org/cmd/go/#hdr-GOPATH_environment_variable [1] For the most part. `go run` works anywhere, for example, but you shouldn't be using that as part of your regular dev cycle. You can also compile and link manually, if you really want to. [2] Strictly speaking, you can get around this requirement, with a latticework of clever tricks and hacks. Some people like to have their repos represent their own GOPATH, and play games with setting a new GOPATH for each new repo/project. I can almost guarantee you that if you start doing this, you will become very frustrated with the language and probably give up on it. [3] Relative imports, like import "./foo", are technically allowed by the compiler, but are widely considered to be a mistake outside of one very specific circumstance having to do with test packages.

snikch 11y ago
Quick note on 3.b - Go 1.5 didn't introduce cross compilation, that's been around for much longer.
- sagichmal 11y ago
  Yes, but before Go 1.5 you had to build the toolchain for each target manually, and with Go 1.5 it comes by default.
bphogan 11y ago
Thank you kindly for this concise and well explained answer. I truly appreciate the time you took with your explanations.