Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in

Issue 5787055: code review 5787055: cmd/go: local import fixes (Closed)

Can't Edit
Can't Publish+Mail
Start Review
4 years, 7 months ago by rsc
4 years ago
dfc, rliebling, aam
golang-dev, bradfitz, yiyus


cmd/go: local import fixes 1) The -D argument should always be a pseudo-import path, like _/Users/rsc/foo/bar, never a standard import path, because we want local imports to always resolve to pseudo-paths. 2) Disallow local imports in non-local packages. Otherwise everything works but you get two copies of a package (the real one and the "local" one) in your binary.

Patch Set 1 #

Patch Set 2 : diff -r f147fef4e17c https://go.googlecode.com/hg/ #

Patch Set 3 : diff -r f147fef4e17c https://go.googlecode.com/hg/ #

Patch Set 4 : diff -r 91a86970157c https://code.google.com/p/go/ #

Unified diffs Side-by-side diffs Delta from patch set Stats (+17 lines, -4 lines) Patch
M src/cmd/go/build.go View 1 2 3 4 chunks +6 lines, -2 lines 0 comments Download
M src/cmd/go/pkg.go View 1 2 2 chunks +11 lines, -2 lines 0 comments Download


Total messages: 11
Hello golang-dev@googlegroups.com, I'd like you to review this change to https://go.googlecode.com/hg/
4 years, 7 months ago (2012-03-08 16:58:00 UTC) #1
LGTM On Mar 8, 2012 8:58 AM, <rsc@golang.org> wrote: > Reviewers: golang-dev_googlegroups.com, > > Message: ...
4 years, 7 months ago (2012-03-09 07:12:46 UTC) #2
On Thursday, 8 March 2012 17:58:00 UTC+1, rsc wrote: > > > 2) Disallow local ...
4 years, 7 months ago (2012-03-09 08:29:53 UTC) #3
On Fri, Mar 9, 2012 at 03:29, yiyus <yiyu.jgl@gmail.com> wrote: > Wouldn't it be possible ...
4 years, 7 months ago (2012-03-09 17:45:06 UTC) #4
On Friday, 9 March 2012 18:45:04 UTC+1, rsc wrote: > > I saw that discussion. ...
4 years, 7 months ago (2012-03-09 18:06:58 UTC) #5
*** Submitted as fc524d42fb8c *** cmd/go: local import fixes 1) The -D argument should always ...
4 years, 7 months ago (2012-03-11 19:53:47 UTC) #6
I'm hoping I misunderstand this. So, please correct me if so. Let me give an ...
4 years ago (2012-10-01 22:10:40 UTC) #7
> Now, if someone else were to fork my project (say to fix a bug), ...
4 years ago (2012-10-01 23:28:32 UTC) #8
> $ cd $GOROOT/src/github.com/rliebling/ > $ rm -rf constant_time_sorting > $ git clone github.com/mirtchovski/constant_time_sorting that's ...
4 years ago (2012-10-01 23:30:06 UTC) #9
> $ cd $GOROOT/src/github.com/rliebling/ > $ rm -rf constant_time_sorting > $ git clone github.com/mirtchovski/constant_time_sorting > ...
4 years ago (2012-10-01 23:30:42 UTC) #10
4 years ago (2012-10-02 16:26:54 UTC) #11
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:

>   Source files are significantly less portable if you are using relative 
> imports,
>   because now you can't resolve anything without knowing where the file 
> came from.

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.


On Monday, October 1, 2012 4:30:44 PM UTC-7, Dave Cheney wrote:
> > $ 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 
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld 80a51fa-tainted