undefined | Better HN

0 pointsgolergka10y ago0 comments

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.

0 comments

sigjuice10y 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.

golergkaOP10y 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.

sigjuice10y 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.

_ak10y 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.

j / k navigate · click thread line to collapse

0 pointsgolergka10y ago0 comments

Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.

0 comments

sigjuice10y ago

golergkaOP10y ago

> It also isn't clear to me how one might have multiple copies of the same project.

git even introduced a feature that is usable precisely for that scenario, worktree.

sigjuice10y ago

_ak10y ago

j / k navigate · click thread line to collapse