Hacker News Reader

Comment by echelon | Hacker News Reader

Why does Go require a special path for projects to be on? Python doesn't. Rust doesn't. This just seems annoying for no particular reason.

View on HN

Python has a list of locations to look for projects (modules) in (sys.path) and by default includes the working directory as the first item in that list.

Go has a list of locations to look for projects (packages) in ($GOPATH) and by default does not include the working directory. Unlike Python's sys.path, $GOPATH normally only contains a single value.

Python's behavior is similar to $PATH on Windows while Go's behavior is similar to $PATH on Unix.

There are pros and cons to each default value but either language can be overridden to have the other's behavior if you desire.

I personally quite like having a single unified $GOPATH for all of my source.

> There are pros and cons to each default value but either language can be overridden to have the other's behavior if you desire.

How? With Python I can release a package with code like `import foo from .` in it. This will not work in Go, a GOPATH package must import things from subdirectories via GOPATH. At least, this was the case the last time I checked.

Vendoring

https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJ...

https://blog.gopheracademy.com/advent-2015/vendor-folder/

Vendoring only works inside a GOPATH; if you're outside the GOPATH, the vendor/ folder is ignored.

https://github.com/golang/go/issues/14566

    There are many problems with running outside GOPATH. Among others, there's no
    caching of built object files, so everything is much slower than it should be
    (go build, go test, and so on). Vendoring is pretty low on the list of problems.

    It may be that GOPATH should be reconsidered but if so it should be done as a
    whole change, not just one piece at a time, like @bradfitz said above. 

    The solution for now is to use GOPATH.

    >  rsc closed this on 6 Dec 2016

Once the new dependency tool is done, it seems like GOPATH will be increasingly irrelevant with vendored dependencies and proper tooling.

(You may also be interested in this extended and active discussion on getting rid of GOPATH; https://github.com/golang/go/issues/17271)

You're absolutely correct—I just tested it, and I'll be damned. That's what I get for never playing around with it, and had (wrongly) assumed that this would have been one of the most basic features of vendoring.

I appreciate the correction!

Yeah, vendoring doesn't fix this problem as the sibling comment says. To be clear, I'm aware the team is aware of the inadequacies of the current system and is working on fixing it -- just saying that this doesn't work well now :)

Yep no worries—I was wondering why you wouldn't have known such a "basic" thing, and now I'm more knowledgeable because of it =)

True, you must put your source within a directory named src.

I think sys.path defaults to PYTHONPATH (+interpreter relative lib path) if it exists

Indeed. I have a couple of Go projects that are released in the classical manner as tarballs, which users can extract anywhere and compile with `make && make install`.

This used to work okay-ish until Go 1.5. Then Go 1.6 introduced vendoring support (i.e. you put the code for the libraries you need into your own repo) which is very nice if it works, so I wanted to have it. But `go build` stubbornly refuses to look at vendored code when you are not in the exact correct location inside the GOPATH.

To preserve the familiar build semantics, I set up the GOPATH inside the repo. Roughly like this:

  $ git clone https://github.com/foo/bar && cd bar
  $ mkdir -p .gopath/src/github.com/foo
  $ ln -sTf ../../../.. .gopath/src/github.com/foo/bar
  $ GOPATH=$PWD/.gopath go build github.com/foo/bar

Of course, all that bullshit can be nicely tugged away in the Makefile. For example: https://github.com/sapcc/swift-drive-autopilot/blob/a3d5d02b...

You can find this either hilarious or sad. I like the irony in using make(1) to patch up the deficiencies of a tool that was created decades after it.

> 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

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

There is a tool called gb that helps you with this

https://getgb.io/

(I have no affiliation with gb)

While we're shamelessly plugging: I actually wrote my own vendoring tool after being confused by the ecosystem. It's a shell script of maybe 30 LOC: https://github.com/holocm/golangvend/blob/master/golangvend

I hope to abandon it for an official solution, though, given that it appears and is good.

Go the language does not require any environment variable (see https://golang.org/ref/spec). Go the tool (that wraps compilations and linking) did depend on $GOPATH environment variable to find location of installed packages (see https://golang.org/cmd/go/#hdr-GOPATH_environment_variable).

In some ways this is similar to cargo which depends on existence of ~/.cargo

btw. you can manually invoke Go compiler and linker. A very simple example from some time ago can be found here: https://github.com/tumdum/go_build

It doesn't. Package imports are either relative to GOPATH, GOROOT, the vendor directory or to the current package path (e.g. `import "../sibling"`).

This doesn't restrict you to using a special path or a particular mode of organizing. Rather, it leaves much of that problem to the user, for better or for worse. It's perfectly fine to write programs with GOPATH unset.

I actually really like that about Go. Not the fact that it wasn't set on standard, that was annoying. But the fact that Python modules can be anywhere as long as they're in some path can be confusing and hard to track down code. The Go mode is very restricting, but it keeps the environment tidy.

Honestly Python does too as soon you start working on multiple project or something larger. Sure virtualenv in Python allows you to specify where you want the project to be, but so does Go, just redefine GOPATH.

Python has PYTHONPATH. I believe it's the exact same thing? The difference is that Python puts the current directory and the standard library in by default.

Reply on news.ycombinator.com