code review 61630048: cmd/go: Possible to build executable with local-package...

cmd/go: Possible to build executable with local-packages on $GOPATH

[mattn, 2014-02-12 09:47:47]

Hello rsc@golang.org, r@golang.org (cc: golang-codereviews@googlegroups.com), I'd like you to review this change to http://go.googlecode.com/hg/

[mattn, 2014-02-12 12:20:39]

R=r, rsc

[rsc, 2014-02-12 16:07:15]

Why? If you are in GOPATH you should not be using local imports. Russ 

[mattn, 2014-02-13 00:10:49]

Ah, I tried this again on latest, but not occured.

[mattn, 2014-02-13 10:15:10]

On 2014/02/13 00:10:49, mattn wrote: > Ah, I tried this again on latest, but not occured. I reproduced this. I want to build on following condition. ------------------------------------ C:\dev\go\src\foo>go env set GOARCH=386 set GOBIN= set GOCHAR=8 set GOEXE=.exe set GOHOSTARCH=386 set GOHOSTOS=windows set GOOS=windows set GOPATH=c:/dev/go set GORACE= set GOROOT=c:\go set GOTOOLDIR=c:\go\pkg\tool\windows_386 set TERM=dumb set CC=gcc set GOGCCFLAGS=-g -O2 -m32 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 ------------------------------------ C:\dev\go\src\foo>dir /b /s C:\dev\go\src\foo\bar C:\dev\go\src\foo\main.go C:\dev\go\src\foo\bar\bar.go ------------------------------------ C:\dev\go\src\foo>type main.go package main import (	"./bar" ) func main() {	bar.Do() } ------------------------------------ C:\dev\go\src\foo>type bar\bar.go package bar func Do() {	println("Do!") } ------------------------------------ C:\dev\go\src\foo>go build can't load package: c:\dev\go\src\foo\main.go:4:2: local import "./bar" in non-local package

[rsc, 2014-02-13 14:47:15]

On Thu, Feb 13, 2014 at 5:15 AM, <mattn.jp@gmail.com> wrote: > On 2014/02/13 00:10:49, mattn wrote: > >> Ah, I tried this again on latest, but not occured. >> > > I reproduced this. I want to build on following condition. > I understand, but we do not want you to do that. Local imports are for throwaway programs outside of GOPATH/GOROOT. If you are in GOPATH/GOROOT you need to use fully qualified import paths. In this case, you can change your import to say "foo/bar" instead of "./bar". Russ 

[mattn, 2014-02-13 16:34:16]

Yes, I know it. But I don't understand why go doesn't allow this. On 2/13/14, Russ Cox <rsc@golang.org> wrote: > On Thu, Feb 13, 2014 at 5:15 AM, <mattn.jp@gmail.com> wrote: > >> On 2014/02/13 00:10:49, mattn wrote: >> >>> Ah, I tried this again on latest, but not occured. >>> >> >> I reproduced this. I want to build on following condition. >> > > I understand, but we do not want you to do that. Local imports are for > throwaway programs outside of GOPATH/GOROOT. If you are in GOPATH/GOROOT > you need to use fully qualified import paths. In this case, you can change > your import to say "foo/bar" instead of "./bar". > > Russ > -- - Yasuhiro Matsumoto 

[rsc, 2014-02-13 16:38:29]

On Thu, Feb 13, 2014 at 11:34 AM, Yasuhiro MATSUMOTO <mattn.jp@gmail.com>wrote: > Yes, I know it. But I don't understand why go doesn't allow this. > Among other things, local imports make the code harder to understand, because you need to know where it came from to resolve what it is importing, and because you cannot grep for the import path to find uses. It also makes the code less efficient to compile, because there is no clear place to install the intermediate packages so that future builds will be faster. Russ 

[h8liu, 2014-02-25 20:16:37]

On 2014/02/13 16:38:29, rsc wrote: > On Thu, Feb 13, 2014 at 11:34 AM, Yasuhiro MATSUMOTO <mailto:mattn.jp@gmail.com>wrote: > > > Yes, I know it. But I don't understand why go doesn't allow this. > > > > Among other things, local imports make the code harder to understand, > because you need to know where it came from to resolve what it is > importing, and because you cannot grep for the import path to find uses. It > also makes the code less efficient to compile, because there is no clear > place to install the intermediate packages so that future builds will be > faster. > > Russ Hi Russ, Talking from my personal experience, what I really would like is not really local packages, rather, I would like some way to locally symbolic link global packages. I love golang, because it is clean and easy to use, where I hate java's 'public static void main() throws ...' shit. And to my opinion, something like 'import "github.com/mattn/gom"' is just as ugly. When I program in go, I prefer splitting a package into small files, and splitting a large package into small packages; it helps improve readability. However, when files and packages are small, these long tedious import lines become more frequent and longer. I totally agree that every package should be only compiled once and put at a designated location. However, due to these long import lines, and since go tools does not support symlinks, the golang community often just use tools that uses "goven" to automatically hard copy packages around. As a result, packages are compiled multiple times anyway. Sure, using local aliased packages will lose the ability to analyze dependencies using simple greps. One have to trace down the link to find the actual package used. Yet I don't think this convenience is that important. A tool that tracing down the sym links would be very easy to build/integrate into go/parse package, and programmer do not use "grep" to figure out dependencies that often. One additional benefit that I really like: package aliasing would allow a package to link with different packages that implement the same public interface signature without changing the actual code. This means people can specify interfaces, make test suites packages and ask for an implementation package that fits. I think this feature could be very useful and important for the open source community, because it provides a way to formalize collaboration at the language and tool-chain level. And without local package aliasing, the only way I can think of to do this is to "goven" the code every time. These are just my personal opinions, but my feeling is, if golang does not support this officially, the growing golang community will just do it in even uglier ways anyway. Thanks. Lonnie

[rsc, 2014-03-05 19:32:34]

R=close