Your go code has to live in go's directory structure. If your project is github.com/jrockway/whatever, then your source code must live in ~/go/src/github.com/jrockway/whatever/<go files>. There is no other place you can put it (though you can change ~/go to something else by setting $GOPATH in your environment).
I assume what upsets people is that everything in go is in a global namespace. So if you have ~/foo-project with some go in it, that doesn't work; you can't import things from there and the compiler won't build it. Instead you have to position it in the "global" ~/go/src for anything to work.
I used to teach Perl classes and people were equally upset about the concept of @INC. They did not want to manage packages that way, and the programming language did not give them a choice. This is very off-putting to some people.
(Me, I don't care. Not having 8000 configuration options to let the compiler find some github project I'm using is wonderful, even if having to cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there ;)
One nit: it's not "global" because it comes from $GOPATH. If you want, you can create a project like this: `~/myproject/src/app/main.go` and it will work fine so long as you set `GOPATH=$HOME/myproject` for your current shell.
It's not that trivial in my experience. I tried hacking my shell so that the `go` command would automatically set GOPATH for me, but then I also had to set GOBIN for some reason, and even then I had to move my repository from ~/code/myproject to ~/code/myproject/src/github.com/myuser/myproject - which is just hugely unnecessary.
> cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there
In addition to your bash alias for navigation, you can use the `autocd` option of bash so that from your home directory you can say `cd /project`.
You can also use the CDPATH variable for quick navigation into a deep directory structure like that.
Go insists that all of your Go code must live inside of a single hierarchy under $GOPATH. This pretty much forces you to organise files in your system in a very particular way, where the language a project is written in takes precedence over any other organisational concerns, and doesn't play well with, e.g. my setup, where I file my projects in a hierarchy shaped like ~/dev/{personal,$COMPANY,3rdparty}/$PROJECT_NAME.
Keep the actual directory where Go wants it to be and create a symlink to it in ~/dev/$who/$project.
Next, create a script that you name as “mygo” or whatever (something short and memorable that makes sense to you. I would probably name it as just “g”) and put it in your ~/bin/ and ensure you have ~/bin in your $PATH.
In said script you resolve the real path of your project, cd there and then execute /usr/local/bin/go with the args that your script got:
#!/usr/bin/env bash
cd "$( realpath . )"
/usr/local/bin/go "$@"
So when you are in ~/dev/someclient/someproject/, you run “mygo build” and the script runs “go build” from the real path of the project. (At first I suggested to name your script as just “go”, but I decided that it was probably better to use a non-colliding name instead and so I quickly edited this comment.)
That ought to do it.
I totally agree with you though. I do similar to you — I keep public projects under ~/src/github.com/ctsrc/$project and client projects under ~/src/$client/$project. If it wasn’t for the fact that I don’t write in Go I would be annoyed too.
Sure, there's decent workarounds to solve this problem, but I take it as a general rule that, if I'm fighting against (rather than with) a tool, I'm either using the wrong tool, or I'm using the tool wrong.
If my fight against a language starts at the "I can't put my source code where I want without having to fight it", it's an uphill battle to convince me this is not a "using the wrong tool" scenario, and I'm happy to take my dev time elsewhere.
I have multiple different languages and code for multiple companies and have no issues. I guess the issue is that you don't want to include the repo location in the path?
I mean I want to have ~/dev/personal/some_go_project and ~/dev/personal/some_java_project side by side, instead of being forced to move some_go_project to ~/go_dev/some_go_project. Java (and, well, just about every other language I've ever touched) is perfectly ok with this, Go isn't.
I was about to ask the same, then after some thinking about it, came to the conclusion that he doesn't like to be forced to save all Go libraries under $GOPATH. Now with Go 1.11 you can have "modules" that you can put all over the place. Much more freedom, right? :)
You see, GOPATH crossed a line. Go is opinionated, which is fine, but with GOPATH its opinions extended beyond my Go work and into the rest of my system. As a naive new Go user, I was prepared to accept their opinions on faith - but only within their domain. I already have opinions about how to use my computer. I knew Go was cool, but it could be the second coming of Christ, and so long as it was annoying to use and didn’t integrate with my workflow, I (rightfully) wouldn’t care.
And just what point is that? The article states that "You see, GOPATH crossed a line. " Doesn't explain what that line is and then goes on to say that Golang is an awesome and simple language.
"...but with GOPATH its opinions extended beyond my Go work and into the rest of my system. [...] I already have opinions about how to use my computer."
Not sure I agree with that statement. Yes Golang has an opinion on where it wants you to keep your go code but it dosen't effect the rest of your system, just your go work.
Sure, but there are 100 other languages out there that do the same thing as Go but don't have an opinion about the organization of my system. I'd rather just use one of those, and really I don't think I'm missing out on much by not using Go.
