49 ms·

GOPATH issues - Elaborate more?

by neduma 8y ago

ofrzeta 8y ago
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? :) https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules
2trill2spill 8y ago
Apparently too lazy to set an environment variable. I found GOPATH annoying but not using Golang simply for that seems absurd to me.
- ofrzeta 8y ago
  That's not the point: https://news.ycombinator.com/item?id=18178987 https://news.ycombinator.com/item?id=18178987
  - 2trill2spill 8y ago
    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.
    - really_operator 8y ago
      He says it in the next sentence. "...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."
      - 2trill2spill 8y ago
        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.
        deleted 8y ago
        [deleted]
        ModernMech 8y ago
        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.
        AnimalMuppet 8y ago
        Where I want to keep my code is not one of the things I grant the language the right to dictate - even if the code is written in that language.
- nerdponx 8y ago
  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.
  - deleted 8y ago
    [deleted]
- Anderkent 8y ago
  Toggling GOPATH between projects is a huge pain, it's not as simple as set it once and forget it.
pdpi 8y ago
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.
- ramenmeal 8y ago
  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?
  - pdpi 8y ago
    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.
- codetrotter 8y ago
  Symlinks are your friends ;) 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.
jrockway 8y ago
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 ;)
- weberc2 8y ago
  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.
  - raziel2p 8y ago
    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.
- malingo 8y ago
  > 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.

GOPATH issues - Elaborate more?

by neduma 8y ago

GOPATH issues - Elaborate more?

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? :) https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules

2trill2spill 8y ago

Apparently too lazy to set an environment variable. I found GOPATH annoying but not using Golang simply for that seems absurd to me.

ofrzeta 8y ago
That's not the point: https://news.ycombinator.com/item?id=18178987 https://news.ycombinator.com/item?id=18178987
- 2trill2spill 8y ago
  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.
  - really_operator 8y ago
    He says it in the next sentence. "...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."
    - 2trill2spill 8y ago
      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.
      - deleted 8y ago
        [deleted]
      - ModernMech 8y ago
        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.
      - AnimalMuppet 8y ago
        Where I want to keep my code is not one of the things I grant the language the right to dictate - even if the code is written in that language.
nerdponx 8y ago
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.
- deleted 8y ago
  [deleted]
Anderkent 8y ago
Toggling GOPATH between projects is a huge pain, it's not as simple as set it once and forget it.

pdpi 8y ago

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.

ramenmeal 8y ago
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?
- pdpi 8y ago
  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.
codetrotter 8y ago
Symlinks are your friends ;) 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.

jrockway 8y ago

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 ;)

weberc2 8y ago
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.
- raziel2p 8y ago
  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.
malingo 8y ago
> 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.