Hacker News Reader

Comment by alexandernst | Hacker News Reader

How about fixing all the GOPATH crap?

We've worked around it like this and it works pretty well: https://github.com/getstream/vg

I'm so undecided on using GOPATH like that. Though, I may just do it.

Personally I hate Go's imports, and I think the GOPATH is a terrible, terrible idea. Yet, I quite like the vendor directory, and I expect the new `dep` tool to be the final touch.

Now my only problem is that I often forget which projects of mine are in my GOPATH, so I'm afraid to delete them -_-

vendor has big problems too. There are some proposals on how to start fixing them, after the dep tool lands (originally slated for 1.7 or 1.8 but still in Alpha?)

To support the uncommon edge case, src/foo/vendor/dep is completely different to src/bar/vendor/dep.

Your src/foo code can't pass src/foo/vendor/dep types to src/bar code expecting src/bar/vendor/dep types. Even if the deps are identical checkouts. Code can become uncompilable by the act of vendoring a dependency.

You have two completely different sets of globals. Code can stop working by the act of vendoring a dependency.

The initialization runs twice. So well known packages like glog will panic if two packages has it vendored because they both try to update settings in the standard library.

GOPATH would be preferable, but none of the tools for managing packages at that level support pinning. So you dare to be developing more than one package at a time, you end up with a single monolithic repository representing your GOPATH and pin your dependencies in src/, or end up with symlink hacks and other unmaintainable tricks.

If you look two parents up you see my colleague posted virtualgo (https://github.com/GetStream/vg). That's the tool I built at my company support GOPATH and version pinning (which is forwarded to dep). You can use it to solve the exact issue you're describing by using "vg uninstall packageName".

Oh I definitely agree there, I didn't mean to say it was flawless. When I wrote that, I was more thinking of the UX of vendoring.

Eg, `import "foo/lib"` pulls seamlessly from vendor, which is a really nice UX if people want to vendor.

With that said, I still think a proper package manager Ala Rust Cargo.toml will be better. Here's hoping Go's `dep` solves this crap basket :)

Thanks for this. For the first time in my six months using Go the 'peek definition' and 'goto definition' options work correctly!

yeah, I don't fully understand this. I've had the least problems with GOPATH than I have with any other language. You literally set GOPATH=${HOME} and it just works.

I think 1.8 addressed the issue.

https://golang.org/doc/go1.8#gopath

"The GOPATH issue" is the requirement that I keep my source code checkouts at any particular path, in any particular structure, to be able to use the toolchain.

Solving the GOPATH issue would be letting me "git clone" a Go project to a directory of my choosing and still use the tools.

I still find it difficult to install and use Go.

Huh. It was dead simple for me.

I'm also curious as to what issues you have come across with GOPATHS

Multiple unrelated Go projects in different repos located in different directories.

No problem at all with very other language, except with Go - not possible!

I want to open cmd.exe (Win) or bash (Linux) and cd to the directory and build. And not configure a GOPATH in the environment variables of the current user or pretend it to the batch script, set it in IntelliJ Go plugin, etc. It so unflexible, so arkward, and there is no reason for this crap at all. So please fix it for Go 2. Thx

make still works. I don't go build, I make build. Yes, you have to set it up for each project, but only once.

Give me cargo for go either way.

This is the sort of thing that makes it hard to get started with Go in my opinion.

It shouldn't be. Set the GOPATH once and use any text editor.

Except you have to set it every time you open a shell. You can’t put it into your .bashrc either unless you only ever work on one project. This workflow sucks:

    $ cd projects/foo
    $ export GOPATH=$PWD
    $ cd src/github.com/company/foo
    $ go build

OP was talking about getting started. I also don't understand why you can't use the same GOPATH across multiple projects, especially with godeps?

Multiple unrelated Go projects in different GIT/SVN repositories. GOPATH experience is painful.

Even if they are unrelated you can still use one GOPATH...

You should try out https://github.com/GetStream/vg, it handles managing of multiple gopaths in such a way that cding to a directory switches you automatically.

I use one GOPATH and work on dozens of projects. I would hate it if I had to change GOPATH often. In Go, if you find yourself fighting the system, chances are you are doing it wrong.

'go get github/user/project && cd $GOPATH/github/user/project'.

And to avoid dependency issues, I use one of the many vendoring tools. Currently 'govend'.

You are limited to one repository. So all your Go projects have to live in one repo.

That's the issue, and it's a big design flaw - do away with this GOPATH

I'm not following you. I work in multiple repos under multiple orgs. I have my personal stuff, my work stuff, projects I've pulled down to contribute towards, and libraries that I want to test out tweaks upon.

I don't have go/src/ checked in. Is that what you mean? If you do that, you are doing it wrong. I have many, many go/src/$org/$project directories, each of them have their own source control (most of which is different git repos). If I am working on my stuff, cd $GOPATH/src/github.com/sethgrid/$project. That is the repo under source control. Do any development I want, push up any changes to that repo. Rinse and repeat. I can then cd $GOPATH/src/github.com/sethgrid/$project2 and do the same. When I want to pull down $project3, I just `go get github.com/sethgrid/$project3` or manually clone it and I can cd over to it and work on it separately.

Maybe I'm not understanding your criticism.

Now we have at least vendor. But this alien-style fixed paths is really annoying - no other language forces such GOPATH crap. Please remove this limitation from Go 2!

What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.

There's no obvious way to separate personal work, from work work, from exploratory work, from any other way you want to categorise your source directories. You just have to chuck them all in the same root and hope you can remember what each project is for.

What? Manage it the way you'd manage any other environment variables, like AWS_SECRET_ACCESS_KEY. That's exactly what a bash environment is for.

You want to manage GOPATH as if it were a secret key!? Not ever storing it in repos, having weird dotfiles storing them locally, having to set up a keystore cluster like consul in production? Yuck.

The point is it's a per-project config. And yeah, there's no reason to store "/home/artur/go" in my git repo - that wouldn't work for my coworkers whose names are not Artur.

Uhh, just keep separate gopaths? I keep a separate go path per project.

That is the reason why GOPATH is an environment variable: so you can change it easily, you own way.

The thing I dislike is how such languages try to abstract away the filesystem representation of packages/modules/libraries/etc.

The conventions and resolution approaches that are needed to accomplish this often end up being opaque, less flexible, and harder to work with.

I much prefer the approach of C, C++, and even PHP to some extent, where the interaction with the filesystem isn't hidden.

When using C or C++, it's trivial to reference a globally-installed library, such as the standard libraries of such languages. It's also simple to reference third-party libraries, or even to include local copies of third-party libraries within one's own source tree. Relative or even absolute paths can easily be specified when referencing external code.

This also gives so much more flexibility with regards to how a project is laid out, and how it pulls in other code or libraries it depends on. I can follow an approach that works for me, for my project, for my team, for my version control system, for my development environment, for my deployment environment, and so on.

I want the language to conform to my needs. I don't want to have to modify my behavior and my environments to conform with what the language's developers deem to be the "right way" of doing things, especially when this isn't compatible with my needs.

Maybe this means there's slightly less consistency with how libraries and dependencies are handled across projects and libraries, but that's a cost that I'm willing to pay, and in practice it actually isn't that much of an issue when using languages like C and C++.

I'd much rather spend a few seconds specifying "-I" and "-L" and "-l" options when compiling or linking than trying to remember a bunch of conventions or how the high level package names end up mapping to the installed modules or libraries.

I'm not saying that the C approach is perfect, or that I'd want other languages to use a C preprocessor like approach of actually combining separate source files just prior to compilation or even execution.

But I would really like it if modern languages didn't try to hide the existence of files and directories so much, and didn't try to force conventions on me. I'd rather deal with the very small cost of explicitly telling the compiler where to find dependencies rather than relying on conventions or opaque resolution processes.

Reply on news.ycombinator.com