Flexible go package search

[groupie]

I know, I know :)) Personal likes and dislikes are no good starting
point to design a tool for the masses :)

But maybe its already there and I am just too dumb to see it.

You build with go, it wants this

gopath/src/project/somemainstuff/
gopath/src/project/package_one/
gopath/src/project/package_two/
gopath/src/project/package_three/

For some reason I cant remember, I followed the go source tree layout
within my projects, i.e.

gopath/src/somemainstuff/
gopath/src/pkg/package_one/
gopath/src/pkg/package_two/
gopath/src/pkg/package_three/

I get the "package could not be found locally". I fixed it but I thought
it could be very helpful in some projects, that you could give go some
more searchpaths when trying to find packages, relative to gopath/src, like

go build somemainstuff -s pkg -s project/pkg would also try to find the
source for imports within gopath/src/pkg and gopath/src/project/pkg. Is
this possible already? Does someone have an example?

Cheers,
C.

[Yohann Coppel]

You can have multiple paths in GOPATH.

Under linux, it looks like:

GOPATH=/a/first/directory:/another/directory/yetanother

see also go help gopath

:)

[Archos]

https://code.google.com/p/go-wiki/wiki/GOPATH

[groupie]

Oh, sure, that I saw. But it will always search src/... below the
gopath, but never src/pkg/...

You see?

[Jan Mercl]

On Saturday, February 11, 2012 12:16:19 PM UTC+1, groupie wrote:

Oh, sure, that I saw. But it will always search src/... below the
gopath, but never src/pkg/...

You see?

AFAIK that works as intended. If package 'foo' is found at $GOPATH/src/<path>/foo.go then its import path is always "<path/>foo". In the case of e.g. $GOPATH/src/project/pkg/foo.go" the import path is then "project/pkg/foo". What import path are you using?

[groupie]

The import within the source file should be "foo". So there is a package
foo, that is found within the src directory of one of the gopath items.

What popped into my mind was that it might come in handy for bigger
projects if you could structure them within the src/project path, like
src/project/network/foo and src/project/gui/bar. Or
src/project/linux_386/foo and src/project/win_64/foo, if that is needed.

The package you import is just foo. Hmm, now looking at this. If I have
a bunch of generic packages, that I use in most of my apps, how could I
reference them without belonging to the project, but within my source
directory. Means if I do go build foo and have my generic packages in
anothergopath/src/generic, not in foogopath/src/foo, could that be done
with some magic command line? Or just a symbolic link would do?

Cheers,
C.

[DisposaBoy]

unless misunderstood the`go` command already handles all that. Why would you structure your project like this: src/project/linux_386/foo, I'mm referring to the linux_386 directory when you can name the relevant files xxx_linux_386.go and put the platform specific stuff there.

There's no requirement that a package be in a `project` that's more of a convention and to prevent namespace clashes than anything else. if your top level directory is github.com/myname/ it means that others can easily install your  package but you need not do that; if you don't intent to share the code then by all means put the package at src/foo at which point you can import "foo"

[Jan Mercl]

On Saturday, February 11, 2012 4:31:16 PM UTC+1, groupie wrote:

The import within the source file should be "foo".

No. Cf. rsc's post "the go command": https://groups.google.com/d/msg/golang-nuts/tLsxO2S4yoQ/V0vAiKbNw0sJ

The specific part is roughly - a mapping between an import path and an URL or $GOPATH/src/<path> must be unique and a it must be a bijection. That's not met by a desire for a project local package to have an import path like "foo".

There's nothing bad in a conclusion that the go command works only while some conventions are followed (the above is one of them) and that anyone else, needing some non conforming conventions, just cannot use the go command and is forced to use e.g. Makefiles, scripts or a any other build system of choice.

I'm also within such "victims" of the go command, though for different reasons (source code generating before a build).

[si guy]

You can alter the go command source to run your code generators.

I hacked a "fix" into cmd/go/build.go of weekly at line 890 (assuming you're using the gc toolchain and no cgo or asm, idk about otherwise) to and run pre- and post-build scripts. Messy, but the tools are open source after all.

[Jan Mercl]

On Sunday, February 12, 2012 10:40:09 AM UTC+1, si guy wrote:

You can alter the go command source to run your code generators.

I hacked a "fix" into cmd/go/build.go of weekly at line 890 (assuming you're using the gc toolchain and no cgo or asm, idk about otherwise) to and run pre- and post-build scripts. Messy, but the tools are open source after all.

find $GOPATH/src/cznic -name Makefile -execdir make \; # works well enough for me ;-)

[Aram Hăvărneanu]

This can't help anyone who wants to use your software. If you can't
use the go command, for whatever reason, use makefiles. A private fork
is just more work for you to do.

--
Aram Hăvărneanu