Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

gopherbot opened this Issue Apr 12, 2012 · 2 comments


None yet
2 participants
Copy link

gopherbot commented Apr 12, 2012

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

This comment has been minimized.

Copy link

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.


This comment has been minimized.

Copy link

gopherbot commented Apr 15, 2012

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

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.