Hacker News Reader

Work is ongoing to solve this: https://github.com/golang/vgo/. GOPATH won't be necessary anymore.

Try this: https://github.com/warpfork/gof

It's pretty easy to declare a GOPATH that's local to your project. I've been quietly doing it for years. The linked repo is just one short shell script that helps do it (on any project; you don't even have to commit the script, and it doesn't change how anyone else develops).

Frankly, I think every highly-productive gopher outside the Google offices uses some form or another of this. It's unpopular to say it and goes against "the community" zeitgeist, but many people will admit it in private if you ask around.

My biggest complaint about the current state of Go dependency management is actually the vendor dir. We never needed it; project-local GOPATH is enough in the first place. Now, we just get the headaches when both exist and are in conflict, or one provides something that should've been in the other (not a problem, until you push, and someone else on the team has to tell you that you didn't vendor enough...)

I made[1] a zsh hook some time ago that allowed you to have per-project GOPATH.

At the root of the project I just have to do `echo 'github.com/username/package' > .gopkg` and after that, for everything I do under that directory tree, GOPATH will be automatically set to something like `export GOPATH="$(dirname .gopkg)/.gopath"`.

I don't use zsh anymore though.

[1]: https://gist.github.com/strkek/294c2f5e6fe94b8303b5121266b27...

nice, you could do something similar using direnv[1]

[1]: https://direnv.net/

It's a blessing when you want to start a new project while offline (e.g. on a plane or train). All your usual dependencies are already there, ready to use.

Not that it justifies any pain, just found it to be a pleasant side-effect.

Sometimes it's worthwhile to just give in and try something new, even if you don't like it. You might discover unexpected advantages. Then go back to what you prefer and apply those lessons there.

Everything would be much better if we all kept an open mind and learned from each-others experiences. It might not always be obvious, but things are usually a certain way for a good reason. Might not be the best or right reason in the long run, but there's always some lesson to be learned.

You could have a global cache folder instead of a global vendor folder.

Exactly. Both yarn and npm cli support this for nodejs.

This seems like a description of NPM in the node ecosystem, they are incrementally solving all these issues.

That’s, like, the opposite of npm though. It does dependencies per project, versioning, and does not impose any filesystem restrictions. Not that it doesn’t have issues.

How is it the opposite of npm?

All of the reasons I listed...?

But npm does all of those...

I know...Golang does the opposite of each of those. Here's some excerpts of the comment we responded to:

> It's distasteful of Go to impose a filesystem layout.

> To achieve [self-contained dependenceis] with Go, one has to set a different GOPATH per project, and then checkout the project deep into that root.

> Given that Go doesn't really do package versioning...