5 ms·

Because it's supposed to be your actual development workspace. To be honest, I think this is one of the most asinine parts of the go development workflow (and t

by stouset 10y ago

Because it's supposed to be your actual development workspace. To be honest, I think this is one of the most asinine parts of the go development workflow (and there are a lot of contenders…). Having to organize all your go projects separately from everything else just because they happen to be developed in that particular language is maddening.

fixermark 10y ago
Java seems to have gone that road. Not sure if it was a bad idea or not.
- Psyonic 10y ago
  In what way did Java go that road? Java doesn't impose any constraint on location across projects.
- StevePerkins 10y ago
  What are you talking about? It's simple to mix Java and C++ (or whatever) within the same project. Wellllllllll... until you actually start to write code against JNI, of course. But the project LAYOUT is simple!
  - wtetzner 10y ago
    > Wellllllllll... until you actually start to write code against JNI, of course. JNA[1] makes things much simpler. [1] https://github.com/java-native-access/jna https://github.com/java-native-access/jna
Manishearth 10y ago
Yeah, this gets super annoying when you need your project written in other languages to contain go code. I worked on the YCM support for godef, we eventually had to fork the library and rewrite paths since there was no way of pinning to a version within YCM. Libraries written with github paths for `go get` do not play nice with living outside of gopath, and libraries written with relative paths don't work with go get (even though this is something that go could support)
- alexbecker 10y ago
  I use a make rule which appends the local go directories to GOPATH before running "go _". Inelegant, but it works.
- jerf 10y ago
  I've got a couple of projects that contain Go code. The Go code does not need to be the top level of the project. I just either check it out into the gopath or symlink it in (usually the former since I've already set up CDPATH in bash to go to the directory the project is living in), and the import paths in my go code point at something like scm.localdomain.com/team/project/go, where the "project" directory is the top level directory for the project that has no Go code in it. This is even fully go getable if you "go get scm.localdomain.com/team/project/go/cmd/whatever" or something.
  - Manishearth 10y ago
    YCM can't require its users to do that, nor can it pollute the gopath which may not be set when it is installed, nor can it rely on that path always being the same or the installed files not being removed. It's fine for a Go project, but this is not a Go project. It should not be forced to change how it works because it wants to contain some Go code.
    - mixedCase 10y ago
      >It should not be forced to change how it works because it wants to contain some Go code. Go is not like Python, the end result is a binary, not interpreted source code. You can simply write a build script that sets a custom GOPATH inside a temporary folder, pulls all dependencies, builds and pops out a binary ready for use; and you can either discard or save your custom GOPATH anywhere for caching purposes.
      - Manishearth 10y ago
        Fair. Note that this wasn't the only reason we had to fork. Go doesn't (or didn't) provide a way to pin to a dependency, so we would have had to fork anyway, and then rewrite all the paths anyway, so I went the way of using local paths in the fork.
geoka9 10y ago
I actually like it. Makes it really easy to share code between my own programs - really handy for "microservice" projects. And if I want to have a Go program in a different source tree, links allow me to do that.
- alexbecker 10y ago
  But how do you distribute such a project? Do you need an install script with any OSS project that includes go code, which sets up a bunch of links in the user's GOPATH directory? I imagine this script would be bug-prone and difficult for most users to debug.
  - regecks 10y ago
    I distribute commercial Go source with a Dockerfile to build the app (and rpm package) and it has been received remarkably well - better than I had imagined. YMMV.
  - geoka9 10y ago
    I've only used Go for SaaS backends but if I wanted to distribute the code to 3rd parties I'd probably use a Dockerfile too.
- takeda 10y ago
  Go is opinionated how things are done, and just happens that its opinion fits yours, the issue is what when it doesn't? With non-opinionated languages nothing is stopping you from structuring your code the same way. Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library. Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
  - geoka9 10y ago
    > With non-opinionated languages nothing is stopping you from structuring your code the same way. With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few. > Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies. Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else? > Some people stated how hard go makes it when you try to have project that utilizes different languages. I've used links successfully, but maybe my scenarios were not complex enough? > Another issue is when you try to use a fork of one of library. Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.
gluczywo 10y ago
You can view GOPATH centered development as a sign of simplicity. Probably not the most elegant thing in the world but the code organization is easy to fix with: ln -s PROJECT_SOURCE_FOLDER $GOPATH/src/
- majewsky 10y ago
  I actually adopted the GOPATH structure for all my repos, with some shell-script tooling (e.g. `cg github.com/foo/bar` is equivalent to `cd $GOPATH/src/github.com/foo/bar`, but clones the repo on first use). While transitioning to it, I indeed found quite a few repos that were checked out multiple times below my $HOME because of inconsistent directory structures.
  - deleted 10y ago
    [deleted]
  - derimagia 10y ago
    I use https://github.com/motemen/ghq https://github.com/motemen/ghq for that, which is really nice actually.
acln 10y ago
I use GOPATH=$HOME. All the code (Go and other languages) lives under $HOME/src.
- bluejekyll 10y ago
  And what about .git? And roots compatible with what other Devs expect?
  - deleted 10y ago
    [deleted]
  - 4ad 10y ago
    What about git?
    - bluejekyll 10y ago
      I was curious about how this recommendation effects other Devs and the .git and other similar paths in the Dev workflow. That is, is the root of each go project effected?
      - 4ad 10y ago
        Sorry, I don't understand the question. I also set GOPATH=$HOME, and all my source code (not only Go) lives in $HOME/src, and I do use git for both Go and non-Go projects (so they have a .git directory in $HOME/src/what/ever/.git), and there's no problem. Why would there be one?
  - nishs 10y ago
    Running GOPATH=$HOME go get github.com/foo/bar would download the package to: $HOME/src/github.com/foo/bar So $HOME will not have .git.
  - Merovius 10y ago
    I don't see any problems with .git. Most go packages use git anyway, it would be pretty amazing if go tooling would break if you have a .git directory anywhere. Re the other question: If you don't run a go command with a path name, it doesn't matter what the directory structure is. I have tons of non-go projects in my GOPATH and build them with the usual tools. No issues.
Merovius 10y ago
FWIW: I instead started organizing my workspace in the GOPATH layout (that is, I have GOPATH=~ and put a C project cloned from github.com/foo/bar at ~/src/github.com/foo/bar too). It also helps knowing where $random_repo was cloned from. YMMV

by stouset 10y ago

fixermark 10y ago

Java seems to have gone that road. Not sure if it was a bad idea or not.

Psyonic 10y ago
In what way did Java go that road? Java doesn't impose any constraint on location across projects.
StevePerkins 10y ago
What are you talking about? It's simple to mix Java and C++ (or whatever) within the same project. Wellllllllll... until you actually start to write code against JNI, of course. But the project LAYOUT is simple!
- wtetzner 10y ago
  > Wellllllllll... until you actually start to write code against JNI, of course. JNA[1] makes things much simpler. [1] https://github.com/java-native-access/jna https://github.com/java-native-access/jna

Manishearth 10y ago

Yeah, this gets super annoying when you need your project written in other languages to contain go code. I worked on the YCM support for godef, we eventually had to fork the library and rewrite paths since there was no way of pinning to a version within YCM. Libraries written with github paths for `go get` do not play nice with living outside of gopath, and libraries written with relative paths don't work with go get (even though this is something that go could support)

alexbecker 10y ago
I use a make rule which appends the local go directories to GOPATH before running "go _". Inelegant, but it works.
jerf 10y ago
I've got a couple of projects that contain Go code. The Go code does not need to be the top level of the project. I just either check it out into the gopath or symlink it in (usually the former since I've already set up CDPATH in bash to go to the directory the project is living in), and the import paths in my go code point at something like scm.localdomain.com/team/project/go, where the "project" directory is the top level directory for the project that has no Go code in it. This is even fully go getable if you "go get scm.localdomain.com/team/project/go/cmd/whatever" or something.
- Manishearth 10y ago
  YCM can't require its users to do that, nor can it pollute the gopath which may not be set when it is installed, nor can it rely on that path always being the same or the installed files not being removed. It's fine for a Go project, but this is not a Go project. It should not be forced to change how it works because it wants to contain some Go code.
  - mixedCase 10y ago
    >It should not be forced to change how it works because it wants to contain some Go code. Go is not like Python, the end result is a binary, not interpreted source code. You can simply write a build script that sets a custom GOPATH inside a temporary folder, pulls all dependencies, builds and pops out a binary ready for use; and you can either discard or save your custom GOPATH anywhere for caching purposes.
    - Manishearth 10y ago
      Fair. Note that this wasn't the only reason we had to fork. Go doesn't (or didn't) provide a way to pin to a dependency, so we would have had to fork anyway, and then rewrite all the paths anyway, so I went the way of using local paths in the fork.

geoka9 10y ago

I actually like it. Makes it really easy to share code between my own programs - really handy for "microservice" projects. And if I want to have a Go program in a different source tree, links allow me to do that.

alexbecker 10y ago
But how do you distribute such a project? Do you need an install script with any OSS project that includes go code, which sets up a bunch of links in the user's GOPATH directory? I imagine this script would be bug-prone and difficult for most users to debug.
- regecks 10y ago
  I distribute commercial Go source with a Dockerfile to build the app (and rpm package) and it has been received remarkably well - better than I had imagined. YMMV.
- geoka9 10y ago
  I've only used Go for SaaS backends but if I wanted to distribute the code to 3rd parties I'd probably use a Dockerfile too.
takeda 10y ago
Go is opinionated how things are done, and just happens that its opinion fits yours, the issue is what when it doesn't? With non-opinionated languages nothing is stopping you from structuring your code the same way. Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library. Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
- geoka9 10y ago
  > With non-opinionated languages nothing is stopping you from structuring your code the same way. With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few. > Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies. Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else? > Some people stated how hard go makes it when you try to have project that utilizes different languages. I've used links successfully, but maybe my scenarios were not complex enough? > Another issue is when you try to use a fork of one of library. Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.

gluczywo 10y ago

You can view GOPATH centered development as a sign of simplicity. Probably not the most elegant thing in the world but the code organization is easy to fix with: ln -s PROJECT_SOURCE_FOLDER $GOPATH/src/

majewsky 10y ago
I actually adopted the GOPATH structure for all my repos, with some shell-script tooling (e.g. `cg github.com/foo/bar` is equivalent to `cd $GOPATH/src/github.com/foo/bar`, but clones the repo on first use). While transitioning to it, I indeed found quite a few repos that were checked out multiple times below my $HOME because of inconsistent directory structures.
- deleted 10y ago
  [deleted]
- derimagia 10y ago
  I use https://github.com/motemen/ghq https://github.com/motemen/ghq for that, which is really nice actually.

acln 10y ago

I use GOPATH=$HOME. All the code (Go and other languages) lives under $HOME/src.

bluejekyll 10y ago
And what about .git? And roots compatible with what other Devs expect?
- deleted 10y ago
  [deleted]
- 4ad 10y ago
  What about git?
  - bluejekyll 10y ago
    I was curious about how this recommendation effects other Devs and the .git and other similar paths in the Dev workflow. That is, is the root of each go project effected?
    - 4ad 10y ago
      Sorry, I don't understand the question. I also set GOPATH=$HOME, and all my source code (not only Go) lives in $HOME/src, and I do use git for both Go and non-Go projects (so they have a .git directory in $HOME/src/what/ever/.git), and there's no problem. Why would there be one?
- nishs 10y ago
  Running GOPATH=$HOME go get github.com/foo/bar would download the package to: $HOME/src/github.com/foo/bar So $HOME will not have .git.
- Merovius 10y ago
  I don't see any problems with .git. Most go packages use git anyway, it would be pretty amazing if go tooling would break if you have a .git directory anywhere. Re the other question: If you don't run a go command with a path name, it doesn't matter what the directory structure is. I have tons of non-go projects in my GOPATH and build them with the usual tools. No issues.

Merovius 10y ago

FWIW: I instead started organizing my workspace in the GOPATH layout (that is, I have GOPATH=~ and put a C project cloned from github.com/foo/bar at ~/src/github.com/foo/bar too). It also helps knowing where $random_repo was cloned from. YMMV