4 ms·

This is the worst thing about Go, in my opinion. I have one directory for my Go projects, and another for everything else. Go takes too much control away from t

This is the worst thing about Go, in my opinion. I have one directory for my Go projects, and another for everything else. Go takes too much control away from the programmer. "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." — Doug Gwyn

tptacek 13y ago
This is the worst thing about the Go build system, is what you mean. I get annoyed by the classpath-seeming directory tree Goland demands (although producing fast binaries I can upload to servers that have never heard of Golang is a fine consolation prize), so oftentimes I just treat Golang the way I do Python or Ruby, with random .go files all over the place, using "go run".
- stormbrew 13y ago
  I don't think the annoying thing about it is the classpath-like thing (and even if it were, it's at least not as bad as that, not requiring a directory for each path component), but the fact that everything is predicated on this assumption that I'm only working on one thing (or ecosystem of things). I don't want project A and project B to be forced to share dependency versions, but Go makes you go to some pretty bizarre lengths to avoid that. I'd rather have a directory for a project and have its dependencies inside that in pretty much any language/environment.
rakoo 13y ago
You don't have to do this. What I do is set the GOPATH to a standard place: $ set GOPATH=$HOME/.local/share/go All my imports end up there. For all my projects (which are hosted on github), I manually create this dir: $ mkdir -p $GOPATH/src/github.com/rakoo (which should only happen once) and then just link my project, where the code lives, to there: $ ln -s $HOME/my/real/path $GOPATH/src/github.com/rakoo (which should only happen once per project), and all is fine in the world, because symlinks work as expected. It's not bothering me enough to have created a supplementary shell script.

tptacek 13y ago

This is the worst thing about the Go build system, is what you mean. I get annoyed by the classpath-seeming directory tree Goland demands (although producing fast binaries I can upload to servers that have never heard of Golang is a fine consolation prize), so oftentimes I just treat Golang the way I do Python or Ruby, with random .go files all over the place, using "go run".

stormbrew 13y ago
I don't think the annoying thing about it is the classpath-like thing (and even if it were, it's at least not as bad as that, not requiring a directory for each path component), but the fact that everything is predicated on this assumption that I'm only working on one thing (or ecosystem of things). I don't want project A and project B to be forced to share dependency versions, but Go makes you go to some pretty bizarre lengths to avoid that. I'd rather have a directory for a project and have its dependencies inside that in pretty much any language/environment.

rakoo 13y ago

You don't have to do this. What I do is set the GOPATH to a standard place: $ set GOPATH=$HOME/.local/share/go All my imports end up there. For all my projects (which are hosted on github), I manually create this dir: $ mkdir -p $GOPATH/src/github.com/rakoo (which should only happen once) and then just link my project, where the code lives, to there: $ ln -s $HOME/my/real/path $GOPATH/src/github.com/rakoo (which should only happen once per project), and all is fine in the world, because symlinks work as expected. It's not bothering me enough to have created a supplementary shell script.