4 ms·

> Unlike other languages where you can just create a directory and get started, Go wants you to put things in $GOPATH. I've seen this complaint a lot and don't

by rakoo 12y ago

> Unlike other languages where you can just create a directory and get started, Go wants you to put things in $GOPATH. I've seen this complaint a lot and don't agree with it. Go just want everything to be accessible through $GOPATH, it doesn't have to _be_ there. Here's how I organize my code: - I have all my dev in ~/dev. Anything goes here, whether it's go, ruby,... it's my workspace - I put $GOPATH where it should be, in ~/.local/share/go - Whenever I need to go get something, it ends up in ~/.local/share/go/src/domain.com/author/package, as expected - When I need my package to be in $GOPATH, I just symlink ~/dev/project to ~/.local/share/go/src/github.com/rakoo/project, so it is visible in $GOPATH After that everything works as expected (modulo some minor quirks I have to do at go install time), and you don't have to have a specific workspace just for go. It's also minimal enough (once per new project) that I'm not too bothered by it.

zzzcpan 12y ago
I don't think you are being realistic. It is a significant additional effort that other languages typically free you from. Not a big problem though, we can write our own tools.
- rakoo 12y ago
  It's only a symlink you create at the start of a new project (not even each package, each _project_), it's really not heavy. An additional step compared to other projects, but overall the cost of managing dependencies is still lower.
falcolas 12y ago
Even easier: just put your files in a directory and run 'go build' in that directory. If you have libraries, put them down lib/lib_name/lib_name.go, and your build from the root directory will work fine. The compiled lib files will not be in your current directory, but that's usually OK. For a working example, have a look at the logstash-forwarder code structure, it's how they do it, and you can build that from any directory you want. And if you really want to set up go path in your current directory, use a make file and set up a target with 'env GOPATH=$(pwd) go install'
- rakoo 12y ago
  2 problems: - libraries are duplicated left and right. If I want to use the same library in multiple projects, it will be in each project's lib (note that this is how you'd vendor, but it's something else) - resetting env for each command you run sounds heavier, and the day will come when you will forget to do it and you'll run into problems.
  - falcolas 12y ago
    Duplication depends on how you pull them in. For 3rd party libs, you'll pull them in via 'go get', and they will reside in the normal GOROOT, which is appropriate. It's just the libs you write for the particular project which would go down the local lib directory. Resetting the env isn't my preferred choice, but if you put it in a make file, it becomes hard to forget. Especially if you are in the habit of reusing make files between projects with a few customizations, which is my preferred setup.
vorg 12y ago
After about 6 months toying with Go, I also ended up doing the same, except on Windows. I need a personal directory where everything I create and edit is stored, and nothing more, so I can easily and frequently do a manual backup of the contents, without the zip containing anything I didn't create. It's a pity though the $GOPATH system doesn't fit in with this style of working.

by rakoo 12y ago

zzzcpan 12y ago

I don't think you are being realistic. It is a significant additional effort that other languages typically free you from. Not a big problem though, we can write our own tools.

rakoo 12y ago
It's only a symlink you create at the start of a new project (not even each package, each _project_), it's really not heavy. An additional step compared to other projects, but overall the cost of managing dependencies is still lower.

falcolas 12y ago

Even easier: just put your files in a directory and run 'go build' in that directory. If you have libraries, put them down lib/lib_name/lib_name.go, and your build from the root directory will work fine. The compiled lib files will not be in your current directory, but that's usually OK. For a working example, have a look at the logstash-forwarder code structure, it's how they do it, and you can build that from any directory you want. And if you really want to set up go path in your current directory, use a make file and set up a target with 'env GOPATH=$(pwd) go install'

rakoo 12y ago
2 problems: - libraries are duplicated left and right. If I want to use the same library in multiple projects, it will be in each project's lib (note that this is how you'd vendor, but it's something else) - resetting env for each command you run sounds heavier, and the day will come when you will forget to do it and you'll run into problems.
- falcolas 12y ago
  Duplication depends on how you pull them in. For 3rd party libs, you'll pull them in via 'go get', and they will reside in the normal GOROOT, which is appropriate. It's just the libs you write for the particular project which would go down the local lib directory. Resetting the env isn't my preferred choice, but if you put it in a make file, it becomes hard to forget. Especially if you are in the habit of reusing make files between projects with a few customizations, which is my preferred setup.

vorg 12y ago

After about 6 months toying with Go, I also ended up doing the same, except on Windows. I need a personal directory where everything I create and edit is stored, and nothing more, so I can easily and frequently do a manual backup of the contents, without the zip containing anything I didn't create. It's a pity though the $GOPATH system doesn't fit in with this style of working.