`pwd` to GOPATH by default?

[Tobias Lütke]

I really like the fact that we now have a go executable that standardizes how projects are build. 

However, I'd love for the tool to always consider the pwd in the gopath. 

Right now i'm typing "export GOPATH=`pwd`" about 50 times a day so that I can build my projects with go install <x>

I've started adding Makefiles ( like http://github.com/tobi/imagery.go/blob/master/Makefile ) to some projects but I'm sure thats against the spirit of including the go tool in first place. 

[John Asmuth]

For a simple project with no packages, you can do "go build s1.go s2.go -o myprog".

[Andrew Gerrand]

Why don't you enumerate your project directories in the GOPATH variable?

GOPATH=/path/to/proj1:/path/to/proj2:...

Or, alternately, why not cohabit packages inside a single GOPATH's src
directory?

Andrew

[DisposaBoy]

if you have to type that more than once you probably wanna put it in a script.

[Sebastien Binet]

On Mon, 23 Jan 2012 23:42:36 -0800 (PST), DisposaBoy <dispo...@dby.me> wrote:
> if you have to type that more than once you probably wanna put it in a script.

I was about to say "just put . in GOPATH as for e.g. PYTHONPATH" but:

2012/01/24 09:23:56 invalid GOPATH ".": must be absolute
package could not be found locally

I suppose this is considered harmful to have '.' being automatically
expanded by go/build ?

-s

[si guy]

Linux? Bash?

add to .bashrc:

alias go='export GOPATH=`pwd`;go'

[roger peppe]

On 24 January 2012 02:52, Andrew Gerrand <a...@golang.org> wrote:
> On 24 January 2012 13:33, Tobias Lütke <tobias...@gmail.com> wrote:
>> I really like the fact that we now have a go executable that standardizes
>> how projects are build.
>>
>> However, I'd love for the tool to always consider the pwd in the gopath.
>>
>> Right now i'm typing "export GOPATH=`pwd`" about 50 times a day so that I
>> can build my projects with go install <x>
>>
>> I've started adding Makefiles (
>> like http://github.com/tobi/imagery.go/blob/master/Makefile ) to some
>> projects but I'm sure thats against the spirit of including the go tool in
>> first place.
>
> Why don't you enumerate your project directories in the GOPATH variable?
>
> GOPATH=/path/to/proj1:/path/to/proj2:...

this doesn't work when the projects are branches of each other and
so have no natural precedence.

> Or, alternately, why not cohabit packages inside a single GOPATH's src
> directory?

this is also awkward if you have several branched versions of the
same project, as the import paths within each version must match
the directory it's held in.

i am managing to work around this (by working on only one branch at
a time) but it's awkward.

[chris dollin]

On 24 January 2012 02:33, Tobias Lütke <tobias...@gmail.com> wrote:
> I really like the fact that we now have a go executable that standardizes
> how projects are build.
>
> However, I'd love for the tool to always consider the pwd in the gopath.
>
> Right now i'm typing "export GOPATH=`pwd`" about 50 times a day so that I
> can build my projects with go install <x>

How many projects do you have? Can't you put each of them on your
GOPATH?

Chris

--
Chris "allusive" Dollin

[roger peppe]

i don't think this'll work.

you don't want GOPATH to point to the current directory,
but the "go root" of the current directory.

one heuristic could be to find the closest enclosing
"src" directory that is alongside a "pkg" directory.

that would probably work in most circumstances.

[John Asmuth]

Easier than this is just "gb" (http://code.google.com/p/go-gb).

Also, this might be more effective, if you really want to do that:

alias go='GOPATH=$GOPATH:`pwd` go'

[Tobias Lütke]

I'm aware of all bash trickery, clearly in reality I scripted my way
around having to actually type this. I'm more thinking about not
frustrating new users to go. GOPATH is a unorthodox concept to explain
to people when I add team members to go projects. Sure I can switch
everything back to gb but isn't the idea of the go tool to create the
standard build system?

Ideally the community creates conventions that allow most go projects
to be a simple matter of:

* checkout source
* cd directory
* go install

What's currently in the way of this? Mostly that GOPATH needs to be
tweaked and that you also have to give the main package as a parameter
to go install. I'd love another convention here that would look for a
main package in the pkg folder and assume that as the install
parameter.

P.S: I find install awkward here as well as it doesn't do what you
expect, i would expect build to do what install does currently and
install to copy things under $GOROOT but i digress )

[Kyle Lemons]

Ideally the community creates conventions that allow most go projects
to be a simple matter of:

* checkout source
* cd directory
* go install

I think the end goal is

go install repopath 

[Edward Muller]

As a relatively new user to go, I can +1 this as a source of confusion.

I also shell scripted my way around things, but it just felt a little
weird and there are still a few things I'm not clear about (dependency
resolution).

--
Edward Muller
@freeformz

[Russ Cox]

We definitely need better docs about how to set up
your source code and your $GOPATH. It's a known
issue and one that will definitely be addressed before
the Go 1 release.

If you really really really want to use the current
directory as GOPATH, and you are using Linux,
you can export GOPATH=/proc/self/cwd. However,
I take no responsibility for the breakage you will
encounter.

Russ