Hacker News Reader

Comment by i4k | Hacker News Reader

> To preserve the familiar build semantics

You are trying to build Go in a way it wasn't designed for.

Go encourages absolute import paths (relative to $GOPATH) and solves a myriad of other language faults in this way. A good benefit is go-gettable projects, where all dependencies can be reached without a setup/configuration file (like setup.py, requirements.txt, and so on).

If you do not try to use Go like other language, your build should be something like:

  $ GOPATH=$PWD/some/path go get github.com/foo/bar

View on HN

> You are trying to build Go in a way it wasn't designed for.

Yeah, I think his issue is with Go's choice to not search the current directory.

The go tools should let you use the current directory, and the "best practice" would have been vendoring to start, relative to the current directory. Then suddenly you see no GOPATH would be necessary at all! For example:

    % mkdir $proj
    % go get github.com/$dep1
    % go get github.com/$dep2
    % vim main.go
    % find .
    ./main.go
    ./github.com
    ./github.com/$dep1
    ./github.com/$dep1/somepkg
    ./github.com/$dep2
    ...

See, then main can import github.com/$dep1/somepkg, and it would be properly versioned and vendored! It falls out in a bunch of other ways of being nicer too IMO.

The currently GOPATH design encourages untracked and complected dependencies, where we're at 1.8 of the toolchain and we're still changing packaging behavior of dependencies.

Note that my project is still go-gettable. I've structured it in such a way that it is familiar both to Go devs using `go get` and to users who know `tar xf && make && make install `.

Reply on news.ycombinator.com