3 ms·

What is horrible about $GOPATH?

golergka 11y ago
The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely. For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly. Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.
- sigjuice 11y ago
  I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.
  - golergka 11y ago
    > It also isn't clear to me how one might have multiple copies of the same project. A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate. For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected. git even introduced a feature that is usable precisely for that scenario, worktree.
    - sigjuice 11y ago
      Sorry, I should have phrased this a little better. What I meant to say was that I almost always have multiple copies of the code that I am actively working on. And if Go has restrictions on where you can place your source tree, then it complicates the ability to have multiple copies of it.
- _ak 11y ago
  I wrote an extension to gb (the go build tool released by Dave Cheney) that uses gb's functionality to determine the $GOPATH where it operates, plus an alias gbpath="eval `gb gopath`", so a simple gbpath sets the right $GOPATH no matter where I am in the filesystem. I should probably release that at some point.

The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely. For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly. Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.

sigjuice 11y ago
I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.
- golergka 11y ago
  > It also isn't clear to me how one might have multiple copies of the same project. A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate. For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected. git even introduced a feature that is usable precisely for that scenario, worktree.
  - sigjuice 11y ago
    Sorry, I should have phrased this a little better. What I meant to say was that I almost always have multiple copies of the code that I am actively working on. And if Go has restrictions on where you can place your source tree, then it complicates the ability to have multiple copies of it.
_ak 11y ago
I wrote an extension to gb (the go build tool released by Dave Cheney) that uses gb's functionality to determine the $GOPATH where it operates, plus an alias gbpath="eval `gb gopath`", so a simple gbpath sets the right $GOPATH no matter where I am in the filesystem. I should probably release that at some point.