Hacker News Reader

Comment by Spiritus | Hacker News Reader

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

View on HN

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.

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.

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

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

Reply on news.ycombinator.com