relative import paths: good or bad practice?
yy
"./mypackage") has recently changed. Now, the go tool can be used to
compile packages which import other packages outside of any GOPATH as
long as relative import paths are used. My first question is, where is
this documented? The language spec leaves import paths as an
implementation detail but, although they are explainned in the
documentation of the go command and "How to write Go code", I don't
see relative paths menioned in any of these documents. Am I missing
anything?
If relative import paths are supossed to work as they do now, I wonder
if it should not be considered good practice to use them when
importing packages from a common repository. For example,
code.google.com/p/go.crypto/openpgp/s2k imports
"code.google.com/p/go.crypto/openpgp/errors". However, if it imported
"../errors" it would make much easier to move the code to a different
location (for example, in a private fork) even to a directory outside
of GOPATH. (I'd like to remark that, currently, this is the only
situation in which the full import path of a package is included in
the repository).
I even think gofix or a similar tool could take care of converting the
paths inside a repository. Is there any problem with this way to
organize code? Would some patches for the documentation and a new
gofix be considered, maybe after Go1 is released?
--
- yiyus || JGL .
Kyle Lemons
yy
> I tend to avoid them. I thought it was included for legacy reasons, and not
> really to encourage use, though I may be wrong.
This is the feeling I had, but I think that in certain situations they
have some advantages.
> While it might make
> directories relocatable, it makes source files and packages fixed with
> respect to their surroundings.
Where is the disadvantage with respect to using full import paths? If
any package was moved import paths would have to be modified anyway.
The location of source files is already more fixed, not less. And, in
addition to allowing to relocate packages locally, avoiding full paths
would make forking repositories in hosting sites easier.
This would only be a convention, so it may be avoided in particular
cases (or be followed only in particular cases).
> I suspect it's also very easy for that to
> break the "go get" compliance of a remotely hosted package.
How? I think there would be no problem as long as relative paths were
only used to import packages from the same repository.
I find very useful the way relative import paths are currently
implemented, I'd just like to know if we can rely on them working as
they do now in the future or if their behavior may change and should
be avoided.
andrey mirtchovski
message: for packages that will never see the light of the open web
and which I want to keep away from prying scripts and SCMs in my
$GOPATH. I find working with the go tool to be a breeze in this
situation -- "go build ." is all I need.
last time I looked at the documentation (to see if ./../lib would
work) I found it described at the bottom of this section:
http://golang.org/doc/go_tutorial.html#tmp_185 (search for ./file).
That's pretty much the only place, and it seems to be missing on
tip.golang.org.
Robert Johnstone
a package less fixed with respect to its surroundings...
Robert Johnstone
as an example, I think the trade-off is worthwhile for packages
loading sub-packages, or vice-versa.
Kyle Lemons
I'm not certain how moving from relative paths to absolute paths makes
a package less fixed with respect to its surroundings...