[go-nuts] symlinks in GOPATH

Ran into same issue. Makes it difficult to symlink forks of projects.

When working with directories outside GOPATH, I always make certain that
they are symlinks into GOPATH, never the reverse. I've found I can always
arrange my workspace to fit this layout.
Using a symlink for a fork without rewriting the imports could be
convenient though.

It's better to stick with the original import path, and not bother
with a symlink. You can put a git remote for every remote fork
in the same repo under the one import path.

It's not supported because symlinks create aliases of packages. The go tool
goes out of it's way to ignore symlinks.

:-(

I'm trying to work out a way of working with some go code checked into a
sub directory in a much bigger respository. The symlink from GOPATH is
the best I've come up with but it doesn't work fully. Most frustrating!

I can use a mount --bind instead of a symlink which works, but is pretty
untidy. Depending on where I'm editing the files I can have goimports
working or version control but not both!

sub directory in a much bigger respository. The symlink from GOPATH

A little OT but can't you just add/append it to your GOPATH?

I think that is the answer - thanks! I don't know why I didn't think of
that before! I thought of putting it at the start of the GOPATH which
splats pkg, bin and go get stuff into your source tree but not at the end.

The setup now looks like this: I have my go workspace at ~/go say and I
append to it the path to part of the bigger repository, eg

GOPATH=~/go:~/BigProject/SubProject/go

within the go directory I have

src/dir/code.go

The only inelegance seems to be checking in a few levels of empty
directories (go, src and dir) which I can live with.

Thanks!

Unfortunately, multiple GOPATHs have somewhat surprising characteristic
that code in a separate path is *sometimes* compiled:
https://code.google.com/p/go/issues/detail?id=3749

This caused severe problems for us when we decided to have a third_party
path for all external code. When we updated the third_party code, not all
developers got the new version when they synced because they had already
compiled the code once.

- Augusto

Yup. I think more people are coming around to the idea of a single GOPATH entry.

Coming around to it? Personally I can't think of any meaningfully *correct* way
to use multiple GOPATHs due to this issue. Using "-a" to reinstall
everything only works if the root go code is user-modifiable, and then is
absurdly inefficient. This feels like a broken feature, and I felt like we
were forced into a single GOPATH.

Hrm...

Seems like having a build flag that ensures freshness across GOPATHs would
be ideal for me. Like a "-f" or "-u" flag (*f*resh or *u*pdated).

I would have really liked to cleanly separate third_party code from our
code, and aside from the recompilation issue it had worked perfectly for us.

- Augusto

Relevant:
   https://code.google.com/p/go/issues/detail?id=6424
   https://code.google.com/p/go/issues/detail?id=8290

Oh it's not /that/ bad.

Reading the code [1] relating to issue #3749 [2],

So put a "dummy" package called "thirdparty" in your third-party GOPATH,
and install with:
go install mypackage thirdparty

This causes the packages of the third-party tree to be included in the
build roots. Problem solved, no drama.

As a corollary, this behaviour enables interesting workflows where you
/don't/ want certain packages rescanned each build.

[1] https://code.google.com/p/go/source/browse/src/cmd/go/pkg.go#741
[2] https://code.google.com/p/go/issues/detail?id=3749

We generally use symlinks into our GOPATHs to support compatibility with
existing repo layouts. For example, I have a checkout directory structure
that has existed way before we ever used Go. Symlinks are then used from
the GOPATH into that directory structure to allow us to build packages with
local changes. We could develop everything in GOPATH, but then we'd have to
instruct every one to do it the "Go Way", which has varying success. We
could reverse it, per James' instruction, but the goal is to make it easier
for adoption.

We've only really noticed problems around the usage of godoc.

Could alternative solutions to the approach of ignoring symlinks in the go
tool be found to specific problems? IMHO, the go tool shouldn't really have
opinions about the underlying structure of the file system. What are the
real problems with aliased packages?

existing repo layouts. For example, I have a checkout directory structure
that has existed way before we ever used Go. Symlinks are then used from
the GOPATH into that directory structure to allow us to build packages with
local changes. We could develop everything in GOPATH, but then we'd have to
instruct every one to do it the "Go Way", which has varying success. We
could reverse it, per James' instruction, but the goal is to make it easier
for adoption.
go tool be found to specific problems? IMHO, the go tool shouldn't really
have opinions about the underlying structure of the file system.

But it does, its an opinionated tool.

What are the real problems with aliased packages?
>

Aliased packages mean you have two versions of the same source with
different names, so you have to independent paths for package I
initialisation.
GOPATH
tool goes out of it's way to ignore symlinks.