Everything is clearer without relative imports although first they seem useful - just as unused variables.
(So I think this will induce just the same flames :-))
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Trust me I can build on this idea for hours and hours.
Well, it is definitely something that needs to be explicitly defined in the spec because http://tip.golang.org/ref/spec#Import_declarations says that the import system is implementation dependent. Meaning that $GOPATH is completely optional for other implementations of the language.
Also what about cases where we have GOPATH=$HOME/foo:$HOME/bar, and for whatever reason we want to import a pkg in bar from another pkg in bar regardless if the importpath is found in foo. The same applies for goroot and foo.
Making relative paths illegal means we should also define $GOROOT and $GOPATH in the spec. We might as well because without relative imports in a go implementation that doesnt want to force the developer to work within a $GOPATH, all package dependencies must either be stored in the default system library lookup path (/usr/lib), or import strings are relative to the systems root. (import "sync" -> "/sync" or "C:\sync" which is ugly)
This argument is very telling. The language implementers need access to relative imports, but regular language users must do without.
--
an explanation about why relative imports should be restricted as a special case.
The explanation for why the go tool supports relative imports makes sense, but it still does not explain the resistance to allowing them for general projects.
You may not be able to go get a relative import, but certainly I can import a package with an absolute path.
There is a genuine use case for relative imports when used to reference sub-packages.
And no, this was not a trick to maintain dead code, but a consequence of collaborating on a package, each of us with our own repository.
The issue of relative imports has recurred frequently. My belief is that the issue rises over and over again is that no one has yet supplied a solid technical reason to say no.
The arguments have either (a) involved believing any proposal for relative imports would also require allow some pathological use case or (b) stating that the implementation would be overly complex, and we don't want to do it.