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 -_-
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.
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 :)
Solving the GOPATH issue would be letting me "git clone" a Go project to a directory of my choosing and still use the tools.
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
$ cd projects/foo
$ export GOPATH=$PWD
$ cd src/github.com/company/foo
$ go build
'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'.
That's the issue, and it's a big design flaw - do away with this GOPATH
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.
Give me cargo for go either way.
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!
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.