GOPATH requeriment

[Thiago Farina]

Hi goers,

I just wanted to ask if one day the requirement of GOPATH will ever be dropped?

I mean, I see this as serious limitation and a lack of freedom when working with Go code.

Why should I be constrained to a single location of where to put my go code?

It would be much more fetterless if I could check out a project from Github anywhere I want, just build it and install (like it is with C and Autotools projects), rather than be forced to put everything under GOPATH.

Best regards,

--

Thiago Farina

[David Symonds]

You aren't required to use a GOPATH. Check out code wherever you want and write a Makefile that calls the compiler and linker, just like you'd do for a C++ project.

[Jason Phillips]

There's also nothing stopping you from setting GOPATH per project, like many gophers do.

[andrewc...@gmail.com]

As other people have said, write a script which just sets it then builds. That being said, the GOPATH variable is the reason why the rest of go works so seamlessly.

GOPATH allows:
zero config go get - the tool knows where to download projects and dependencies.
It gives you zero config autocompletion in text editors - they know where to find all source files.

I personally prefer this to having ide project files cluttering things.

[Thiago Farina]

On Sun, Apr 19, 2015 at 8:30 PM, Jason Phillips <jasonrya...@gmail.com> wrote:

There's also nothing stopping you from setting GOPATH per project, like many gophers do.

That does not seem to be easy as it may sound.

You may be able to help me understand how it would works though.

Take this example from https://skia.googlesource.com/buildbot/+/master/README.md.

It says to checkout it using:

$ go get -u go.skia.org/infra/...

Now assume I have checked out the buildbot tree in ~/skia_infra/buildbot (using either the fetch command described in the readme file or git clone).

From go documentation, GOPATH would be something like ~/golib or ~/gocode, whatever.

How would I change GOPATH in this example?

In C language we don't have to set any environment variable pointing to some part of the tree to start building anything.

Maybe I'm just miss-understanding how this is supposed to work.

Note: I don't wan't to end up with two checkouts of the same repository. One where I want and another where GOPATH is defined.

Best regards,

-- 

Thiago Farina

[Shawn Milochik]

See this, it should help:

https://golang.org/doc/code.html#GOPATH

You can have multiple items in GOPATH, just as you can in PATH. And you don't have to set environment variables, as others have noted, if you want to do a slightly more manual compile process.

Once you've read the above, you should be able to see how you can have a separate GOPATH per project, with each project's GOPATH containing its custom location and a "common" location you use when you "go get." Whichever path is first in your GOPATH is the location that will be used for "go get," at least in a test I just did locally.

[Egon]

On Saturday, 18 April 2015 23:56:50 UTC+3, Thiago Farina wrote:

Hi goers,

I just wanted to ask if one day the requirement of GOPATH will ever be dropped?

I mean, I see this as serious limitation and a lack of freedom when working with Go code.

Well the limitation means that most go programs can be compiled with go get ...

(Of course there are exceptions.)

My experience with autotools/makefiles etc. are much worse... i.e. setup a new system, download tar, start building -> you are missing X, Y; start building -> you are missing Z, W... etc.

GOPATH solution doesn't work always and has its problems, mainly letting go of your previous habits :)...

For example Camlistore has a separate go program that build the whole thing https://github.com/camlistore/camlistore/blob/master/make.go.

Basically stick to GOPATH as long as possible.

[Tamás Gulácsi]

Just for completeness, camlistore IS go get-able, that make.go "just" compiles everything (main program (camlistored) plus supporting programs (camput, camget, cammount...) and tools (camdev) and assets (for the web page) in a separate build env.