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