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

Closed
gopherbot opened this Issue Apr 12, 2012 · 2 comments

Comments

Projects
None yet
2 participants

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
Contributor

rsc commented Apr 13, 2012

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.

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

gopherbot locked and limited conversation to collaborators May 16, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.