Looking at your program’s structure in Go 1.7

Re:Looking at your program’s structure in Go 1.7 by mappu on Tuesday August 16, 2016 @05:23AM (#12296330)

I've come around to GOPATH after hating it originally. It forces you to be somewhat explicit about your package relationships, the package's name, how it finds everything it imports, and how other packages see it. It's doubly important in a language where packages are the compiler's translation unit. The fact is that every language has these problems, GOPATH only makes you confront them - in a standard way, whereas in other languages, you would run into and make a different ad-hoc solution for every project.

C++ is a great example of a model to avoid (pkg-config handles dependencies, except use autoconf for crossplatform, except cmake is newer and supports windows, except then you should use cmake modules instead of p-c, not to mention qt having its own qmake, ...).

Chaining GOPATHs with : can be very useful (just like PATH).

You can use `gb` if you want a "typical" one-folder-per-project workflow.

[ Parent | on HN ]

Re:Looking at your program’s structure in Go 1.7 by jacques_chester on Tuesday August 16, 2016 @07:58AM (#12296816)

GOPATH is an obnoxious neighbour. Most other systems try to play nice.

> The fact is that every language has these problems

Other languages solve them with proper module or library systems.

Rubygems + Bundler is still the standout in this field. Based on my day job, bundler still better at the basic job of "get the stuff I need" and "keep the stuff I need" than any of Pip, NPM, Godep, Composer, Conda and I forget the rest.

> whereas in other languages, you would run into and make a different ad-hoc solution for every project.

It depends on the language. Ruby and NodeJS have clearly dominant single systems. Rust has one by design. Python is a bit of a mess but Pip seems dominant, with Conda for scientific packages. PHP has Composer, which makes a lot of things tolerable, but not great. Go package managers are not really settled, between Godep, Go vendoring and Glide.

[ Parent | on HN ]

Re:Looking at your program’s structure in Go 1.7 by stouset on Tuesday August 16, 2016 @12:44PM (#12298663)

Except make, cmake, and autotools handle a completely separate problem which `GOPATH` has nothing to do with.

Yes, being able to `go get` is great. Except `GOPATH` doesn't make it any more or less possible, especially now that `godep` is widely used. And that breaks down completely when you actually need to build something that consists of more than just go source. Protos, multi-language projects, etc.

[ Parent | on HN ]