Hacker News Reader

Comment by burke | Hacker News Reader

I interpret this as encouragement to use fully-qualified package names (eg: https://github.com/burke/zeus/blob/master/go/zeusmaster/zeus...), which I don't really have a problem with.

Go code is nothing if not explicit.

View on HN

How do you manage dependency versions with a fully-qualified package name?

There's no explicit versioning unless you do a fork (which effectively puts the version into the import path). When doing open source work, you just assume that the latest version works. If it doesn't, you can complain and check out an earlier version instead (locally), or in the worst case, fork the code until it's fixed and change your import statements to point to the forked version.

For a company, it makes sense to check your GOPATH into your own source control system, so everyone has the same version of the open source libraries you're using. Then upgrading some open source libraries to a new version is a commit like any other change.

That approach is nice and all if we are dealing with modules which we wish to reuse. If instead we would like to organize our source tree following a deep directory structure, we are forced to screw around with $GOPATH, which is a braindead idea.

Huh? You can literally just set $GOPATH to any directory. The only stipulation is that you put your source code in a 'src' folder. That's literally all you have to do. I'm going to go out on a limb and guess you're one of the people that cries in IRC and can't be bothered to read either of the pages that detail the design and use of the `go` tool.

You keep asserting that this $GOPATH is "braindead" but you provide no meaningful criticism of it or suggest any better alternatives.

I haven't messed with Go, but nothing about the idea of defining a path for source modules sounds braindead on its face to me. I certainly would give the benefit of any doubt to the designers of Go over some random troll.

These are not source modules I'm talking about. If it was only necessary to set $GOPATH to point to source modules then everything would be fine. The problem is that go requires that $GOPATH points to a project's source tree to be able to build it, if the project is organized to store other go source files in subdirectories. We aren't talking about packages or modules intended to be reused in other programs. We are talking about how source code trees are organized.

The problem is that go requires that $GOPATH points to a project's source tree to be able to build it

How is that different than the /I ${INCLUDE} path of C/C++ compilers (and many other languages)?

Reply on news.ycombinator.com