go get should support relative import paths (e.g. "./foo")

[gopherbot]

by kballard:

Go source files can use relative import paths (e.g. import "./foo") to specify
packages relative to the current file. However, `go get` doesn't understand these paths.
It should be smart enough to allow relative paths, evaluating them against the path to
the current package, and only complaining if the path tries to descend too far (e.g.
outside of the root of the enclosing source repository).

Not only will  this make it easier to be `go get`-compatible, but it also fixes the
extremely annoying problem of having to update all import paths that refer to
sub-packages when forking someone else's project (and the ensuing problem how to
contribute back to the original project without including these path changes).

go version go1 on darwin

[rsc]

Comment 1:

Not supporting local imports was a very deliberate decision.  We understand the
advantages, but there are also disadvantages.  The most important one is that you cannot
tell what a source file imports unless you know where it was found: copying a source
file changes the meaning of its imports.  This is not a good property for a language
that is trying to be explicit and clear about dependency management.
So, sorry, but we're not going to allow local imports in go get'able code.
Also note that when you use local imports in other code, it means you are giving up on
incremental compilation: the object files for local imports are never installed, so they
cannot be reused.

Status changed to WorkingAsIntended.

[gopherbot]

Comment 2 by kballard:

How common is it to copy a single source file out of an entire project, and still expect
it to work? I can't think of any other languages that have that property. In fact, even
in Go I can't copy a single source file out of a project and still expect it to work,
because packages can be (and often are) split up across multiple files. And if I'm
copying all of the files in a package, it's not that much of an imposition to copy
sub-packages.
I would understand this as an argument against allowing ".." in an import path, but it
just seems like a very weak argument against allowing "./foo".