Is there any standard way to setup GOPATH per project?

[bronze man]

I had tried serval ways to manage my golang library and share them with others:

go get 

One GOPATH in one computer,

Set GOPATH and GOROOT in /etc/bash.bashrc

The main problem is that `go get` is slow in china.

It works with vpn, but it is much slower than a single git project.

And setting up private golang library is also a burden.

one GOPATH one project

Put all code and dependence in one project.

Put all golang code into one git project.

May add a git project in sub directory,but also commit that code into root git project.

Use `kmg gorun` to work around GOPATH setting stuff.

I used to set GOPATH in each project,it is a burden for me to set GOPATH each time in command line,so I write a kmg gorun to work around this problem.

I put a `.kmg.yml` file in my project root path, so my tool can find where the GOPATH is.Then it can use go run or go test to do whatever i want.

I think it will be better to have something like `.kmg.yml` as a standard way.

Is there any standard way to setup GOPATH per project?

[chai2010]

I use three GOPATH:

set GOPATH=C:\go\gopkg.temp;C:\go\gopkg.stable;D:\work\proj;

1. first is for `go get`, it is a temp GOPATH

2. second is stable packages, created by hand(disable `go get`)

3. third is for project develop, created by hand(disable `go get`)

The second and the third GOPATH can use private Git Repo.

If you find a good package in first temp GOPATH,

then move it to second or third GOPATH.

The practice works well in china.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

https://github.com/chai2010

[bronze man]

Thanks. 

It should work well in china.

But how you fix the setting GOPATH again and again problem when you change from this project to another project?

[chai2010]

The third GOPATH is for big project.

The small project can put in the first GOPATH.

IMO, the perfect solution is improve the go command to enable the relative import path.

Every standalone package or application use the relative import path for internal packages.

And enable the internal gopath.

The $(project) root and sub dir has many .gopath dir for internal gopath(like a .git),

the go command can search the .gopath recursive.

But i guess the Go team donot agree this proposal...

[Yang Fan]

I use command line under bash:

GOPATH=$PWD/../..:$GOPATH go build 

or

GOPATH=$PWD/../..:$GOPATH go install

Only common third party libraries are put in GOPATH exported in bashrc.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Fan Yang

[Kamil Chmielewski]

W dniu czwartek, 26 lutego 2015 02:28:11 UTC+1 użytkownik bronze man napisał:

But how you fix the setting GOPATH again and again problem when you change from this project to another project?

This is my biggest problem with Go ecosystem. How to manage dependencies in a way that is repeatable, automated and reliable? I'm using Java, Python, Nim and Rust where I can download any project source code and get all dependencies with correct version using one command. It's a way ahead of the 'go get' in README.md :/
I found https://github.com/Masterminds/glide and I'm using it for every project in Go that I need to work on.

[bronze man]

I think relative import path is a bad idea.

It is not easy to find a path with relative path.

go 1.4 already has internal package, please see http://golang.org/src/internal/ 

[chai2010]

Relative import path is good for sub internal packages.

It is esay fork package.

I hate use absolute path for internal packages.