[golang-dev] Re: code review 5787055: cmd/go: local import fixes (issue 5787055)

there is a trick to this which most go programmers working with github
are aware of, say that i forked your github repo, my fork will be
called 'github.com/mirtchovski/constant_time_sorting. to work with it
without having to change any import paths i would:

$ cd $GOROOT/src/github.com/rliebling/
$ rm -rf constant_time_sorting
$ git clone github.com/mirtchovski/constant_time_sorting

that replaces your repository with my fork but doesn't change any import paths.

Or even easier

cd $PKG
git checkout master #don't blame me for this git facepalm
vim vim vim
git commit
git push $YOURFORK

Thanks everyone for the suggestions of how to cope with this problem.
However, while these approaches help an individual cope, they are, in my
view, not well suited to team development where the team cannot wait for
the patch to be accepted.

They will instead import their own fork of the 3rd party library until that
time. Meanwhile, they will have to have one version to submit a patch, as
described in the several responses to my original question, and another
version to actually reference in their code. Consider also the case where
a hierarchy of repos is used for a project, with different gatekeepers at
the different levels (eg used by linux, but presumably used in other
projects, as well.) In this case, again, one cannot simply accept standard
patches from the lower repos because import statements will need to be
changed to move the code from one repo to another.

Russ stated earlier:
My contention is this addresses the wrong problem. First, the standard
unit of reuse should be the package, not the source file. Source files in
Go are already hard to reuse just by copying to another package, as the
file likely depends on other files in the same package without any explicit
reference to those files. But, more importantly, i think the github
approach to code reuse is significantly more common and more important. In
this approach one uses some open source library (eg using rubygems/bundler
in ruby), specifying some version constraint, btw. When the need arises to
make your own changes/fixes/enhancements to that, you fork it, and use your
own fork up until your changes have been accepted by the original
maintainer (if ever). This approach has led to flourishing development
communities with constantly improving libraries. Encouraging instead a
system where developers merely appropriate individual source files for
their own use runs counter to this approach.

But, maybe the point of all this is that we should just not use "go get" or
"go install" because the package management aspects leads to these
difficulties. I see two paths:
1. never use 'remote imports': treat all packages as local so this
requirement vanishes. Someone writes a package management tool for Go that
behaves this way and life gets better.
2. Separate the notion of the source repo for the code from the directory
and import naming scheme. Esssentially this is how java works, where
packages might be named com.facebook.api.something, but the source code for
it might come from your local fork of the project or someone else's.
Again, someone needs to write a tool to make this easy to get code and
build it. (Please don't make everything xml, like java/maven/ant.)
The bottom line seems to be that "go get" and "go install" don't cut it.

The current situation creates annoying friction to collaboration with Go.
The result will be less collaboration, which will be a loss for the whole
Go community. I hope you will reconsider this issue. The answer need not
be allowing local imports. But, something in my view needs to be done to
eliminate the friction of forking a Go project involving multiple packages.

best,
rich

that's GOPATH, of course.