Hacker News Reader

Comment by deallocator | Hacker News Reader

I must admit I was kind of hoping they'd fixed their horrible requirements for your directory structure, interesting article nonetheless

View on HN

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code.

For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

That's what sucks though. I don't want a "gocode" folder and a "code" folder. It also doesn't fit very well in a monorepo with mixed languages.

We had a small benchmark tool written in Go. And people simply couldn't build it, they always came to me after banging their head trying.

This is basically what all of them did:

    $ cd <folder with all their projects and code>
    $ git clone <repo>
    $ cd <repo>
    $ go build

And obviously it failed because it wasn't in a "src" folder (it was in a git, projects or code folder) nor had the $GOPATH environment variable set. But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get.

They just want to clone anywhere and run "go build".

> But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get.

You obviously didn't vendor your dependencies in your project's vendor directory.

Vendoring doesn't work outside $GOPATH

Why is this the case?

Don't work outside $GOPATH. Set a temporary one if you want a completely isolated environment for one-off building purposes.

Then what's even the point in the first place?

Development. Which is why I said "for one-off builds".

It didn't have any external dependencies, only multiple packages.

I found vendor directories to be documented in a confusing way, so I'm not surprised.

https://golang.org/cmd/go/#hdr-Vendor_Directories

I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.

If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.

> You obviously didn't vendor your dependencies in your project's vendor directory.

You shouldn't have to!

A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.

Even if one vendors the external dependencies, the code that uses them must still be on GOPATH or the compiler would not find them. This is at least with go 1.6.

I agree on the point where it doesn't work well with mix languages. we can, however use `go get` rather than manually doing a git clone.

I understand it'd be a pain to have Go setup, but once it is setup, it is great, When I write Go programs

I do

`$ cd /go/src/github.com/thewhitetulip/Tasks` `$ Tasks go build -o tasks` `$ Tasks ./tasks`

How is this different from any other language where you "just" run `cd path/to/project; (make || rake || pants || cargo)`? This isn't special, and it's not something the go workspace makes possible.

This is different because $GOPATH is a requirement of the language and in _other_ languages, you have to manually clone the repos in the correct root folder which you store all your code into.

Go allows you to do a go get reponame and it'll do the git clone stuff for you.

that is nothing short of amazing as far as code management is concerned. I love it.

Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`.

You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.

Yes, there are silly workarounds. The whole point is that it's a PITA to work with and breaks many common workflows for scant few actual benefits. Especially now that `godep` is in wide use, which just artificially creates the go workspace structure from in-tree dependencies anyway.

What if I don't use Makefiles, because I live in the 21st century?

That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented."

Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them.

Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us.

A good tool to solve a fundamental problem is still useful, no matter how old it is.

You could make a shell script instead.

Take a look at [gvm](https://github.com/moovweb/gvm) I create (similar to a python virtualenv) a pkgset, and then use `linkthis` to link my current directory as a certain path in my gopath. You could do it yourself with symlinks, but I've been loving the tool for other things it provides, too (like easy access to new versions).

You can feel free to have any repo path you want :D

I agree. I think the real problem is that they are using environment variables for this. Environment variables just aren't user friendly, especially on Windows.

It would be better if Go just downloaded all `go get` packages to some default fixed directory (%appdata%/go or whatever), and then the code the people manually download/write could live anywhere.

On another note, I suggest you work around this limitation, you can write a benchmark in Go in the $GOPATH of your company or anything and then use `go install` to install it to the $PATH of your machine, so you can call the benchmark directly. This will separate the codebases.

Otherwise you can write the other language code in the $GOPATH itself.

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit.

Aside from that, I do enjoy the language a fair amount.

You can always symlink a project located in your GOPATH to your `projects` directory.

It's brittle and confusing nonetheless. Having to set up Go on all the machines I use is a pain I could do without.

Then don't? This is just being opinionated in the other direction and declaring yours the right one.

This is inane. The approach GP is talking about lets any developer manage the space above their project however they care to. The `GOPATH` approach forces this one structure upon you.

It's like arguing that marriage equality violates your right to believe a marriage is between one man and one woman. One side is arguing that folks should be able to decide what's best for themselves, the other is saying it must be their way. One of these perspectives forces their preferences on the other. And it's not the GP.

The `GOPATH` approach forces this one structure upon you.

That's basically the point.

It's like arguing that marriage equality violates your right to believe a marriage is between one man and one woman.

No, it's more like the Pythonic "There's one way to do it."

> No, it's more like the Pythonic "There's one way to do it."

Nope, because it's "There should be one obvious way to do it." and you can still do the non-obvious way if you prefer.

It doesn't force anything upon you.

How many machines do you develop in? go getting and ln -s in your code folder isn't exactly an ardous, confusing task.

You can make a sub directory of your `projects` your GOPATH.

Something like `projects/go`

I have multiple GOPATH for personal reasons and use long running tmux sessions which exports the different GOPATH.

That's what I currently do. It's really just a minor annoyance, but it is an extra layer of friction for any newcomers to the language (and a pretty bad first impression)

I use a `.gopath` file and some small shell support[0] to just `cd` into a go workspace among many. That said, the "clone and be done" approach is something I miss sometimes.

[0]: https://github.com/lloeki/dotfiles/blob/master/shell/go

Its almost exactly the same as gradle java projects. Each module there has a 'src' directory where all code and whatnot lives. And nothing's stopping you from having a one-liner bash script that sets up the base as the GOPATH and then running `go build`/

I don't think it is at all same. You can clone a Gradle-based project anywhere (e.g. /projects), cd into that directory and run `gradle build` and it will work. There is no `GRADLE_PATH` or similar environment variable determining where all your Gradle-based projects must live.

The `src` folder you are talking about is a sub-directory inside a Gradle based project. This is entirely configurable within the Gradle build script, you can use multiple sub-directories for your source code or even the same directory as the build script if you wish. The reason Gradle uses a single `src` sub-directory by default is that it follows the Maven Standard Directory Layout.

> But Go has to be special and use a special directory or else it throws a hissy fit.

I just set GOPATH=$HOME, and then all my source (Go & otherwise) is in ~/src, all my binaries (Go & otherwise) are in ~/bin, &c. It works really well for me. So some of the subdirectories of ~/src are a bit funkily-named: no big deal.

This forces me to use a single clone. I can't work on multiple features simultaneously in different build dirs.

This is incompatible with path dependencies. When I was working on the YCM goto support for Go I had to rewrite all the imports in godef to be path imports because you can't go build packages with github deps outside of gopath. This rewriting had to be done in each file (and forced us to fork the package).

We wanted to use godef as a local folder because YCM wants to be able to pin to a version, usually via a submodule. `go get <github>` will be affected by silent updates.

Having everything in $GOPATH has the advantage that all your go code is in one place, but it's not much of an advantage because it's not flat -- you have to `cd github.com/<someusername>/<reponame>` whereas my regular `code` folder has a flat structure, with subfolders only for special cases (e.g. projects with multiple linked repos or whatever).

There are tons of disadvantages, which totally overshadow the minor advantage of automatically giving you a `code` folder -- something which is super easy to do without the "help" of GOPATH.

Fortunately a lot of these things get solved by vendoring, glide, and friends. Bare GOPATH is still terrible.

It's problematic for dependency management. It's almost perfect but what would be better would be to be able to switch easily between different $GOPATH. One per project.

We can already create multiple ones.

I've simply started using $GOPATH for everything. Even my non-Go projects live under $GOPATH/src/<url-to-repo> . I know many people are very particular about the way they work but I did not have any trouble adapting to this, and in the end I found it much easier to manage my projects.

My only problem now is that I have so many projects checked out that it's hard to remember which ones I am contributing to vs which ones were checked out as a dependency. I think I can address that by setting GOPATH to ~/thirdparty:$GOPATH or something, but it hasn't bothered me enough yet.

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.

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.

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.

Reply on news.ycombinator.com