Ignoring any stdlib/runtime pragmatism, the only important use-case I've
seen for non-url imports is in dealing with multi-package public project
code in forks. For example, if I fork <github.com/bradfitz/go-smtpd> into
<github.com/extemporalgenome/go-smtpd>, especially if my intentions extend
beyond authoring a simple pull request, right now I'd have to change all
bradfitz import references in the 'ajas' subpackage to be
'extemporalgenome' references. iirc, relative imports are already forbidden
for being used for this purpose (and even if they were usable, they'd still
be a fairly inelegant solution).
I think this is still a problem that, while relative imports could have
solved them, should not be used to solve them. Ignoring potential
implementation ambiguity, a better human-understandable approach would be
to introduce (in the implementation, not in the langspec) a notion of a
"project root", and require all paths be either absolute w.r.t.
GOPATH/GOROOT, or absolute w.r.t. the project root. For
"github.com/bradfitz/go-smtpd/ajas", the project root would be
"github.com/bradfitz/go-smtpd", and from within ajas, an import of
"//smtpd" (or some other syntax besides '//', preferably not involving
'..') would refer to "github.com/bradfitz/go-smtpd/smtpd" for Brad's
original, and in my fork, would refer
to "github.com/extemporalgenome/go-smtpd/smtpd" in the case of my fork.
In terms of implementation, most of the time it'd just "work" for known
code-hosting systems (and would be unavailable for use in the stdlib). The
cases where ambiguity would crop up would be like "labix.org/v2/mgo" --
without being a supported code hosting system, or without having some
manifest file (which IMHO would set quite a bad precedent), there'd be no
way for the go tool to know if "labix.org/v2" is a static prefix (and that
"mgo" itself is a project), or if "v2" or even the "/" is a project. Doing
a parent-traversal of trajectories can find reasonable candidates, but
simply creating the directory "labix.org/v2/mgo/v2" could completely alter
the behavior of importing "/v2" from within the mgo package. Because of
this, even organizationally saner approaches can have prohibitive
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 email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.