<p>Hi,</p>
<p>I am using global $GOPATH to ~/go where {bin/, pkg/, src/} live.
Til now I was just playing with go without any issue... but now I am going setup a project with other guys...</p>
<p>There are many many GOPATH, vendor, version, pkgs managers on github... and as a newbie I got confused...</p>
<p>Then I found this <a href="https://github.com/golang/go/wiki/GOPATH">https://github.com/golang/go/wiki/GOPATH</a> where I think the message is:
"have a primary $GOPATH to store shared/contrib pkgs' and a second per-project $GOPATH set"
Am i correct?
If so... should I do this:</p>
<pre><code>#~/.bash_profile
goset(){
export OLDGPATH=$GOPATH
CURDIR=$(pwd)
if [[ -d bin && -d pkg && -d src ]]; then
printf "Already a project...\n"
return 1
cd $CURDIR
else
PRJ=$@ ; [ ! -d "${PRJ}" ] && mkdir -p $PRJ/{bin,src,pkg} && cd $PRJ || cd $PRJ && export GOPATH=$(pwd)
printf "Loaded ${PRJ} to GOPATH...\n"
fi
}
</code></pre>
<p>then...</p>
<pre><code>source ~/.bash_profile
goset projectA
#playwithit
gounset
#lunch
</code></pre>
<p>Or any other simple way I am missing here...?</p>
<p>Thanks in advance,
includex</p>
<hr/>**评论：**<br/><br/>natefinch: <pre><p>That is what it's saying, but I actually think it's bad advice. It just complicates things. You don't need a separate GOPATH for your own projects. They'll be accessible under the default GOPATH in their usual place (i.e., for me, $GOPATH/src/github.com/natefinch). I actually think it's confusing to have two gopaths, because then you have to think about whether or not code is "your" project, or someone else's and look in different spots to find them... and if you happen to have the same package in both places, one will override the other, which could be confusing. </p>
<p>Since all packages by definition have unique addresses according to their repo URL, there's really no reason not to have a single gopath for everything.</p></pre>natefinch: <pre><p>Note, after posting <a href="https://github.com/golang/go/issues/13225">an issue</a> on this, Andrew Gerrand agreed with my assessment and indicated I should update the wiki to remove the advice, so I have done so: <a href="https://github.com/golang/go/wiki/GOPATH#use-a-single-gopath">https://github.com/golang/go/wiki/GOPATH#use-a-single-gopath</a></p></pre>include007: <pre><p>Super!! Many thanks for clear this up for us (newbies)</p></pre>vividboarder: <pre><p>This seems like the equivalent of Virtualenv with Python. </p></pre>ericanderton: <pre><p>When using Go in an enterprise capacity, that's kind of what you need. Project-specific dependency graphs and versioning really do matter; lumping every project's dependencies together in a huge tree will break things.</p></pre>slrz: <pre><p>So what you're saying is that "enterprise" means you're swamped with so much crap code that you're no longer able to discern what shit ends up being compiled into your binary?</p>
<p>Sounds about right. I'm not so sure about your proposed solution, though. How is anyone able to understand the mess if you add even more code (different library versions, one per project) to it?</p></pre>include007: <pre><p>How about this tool <a href="https://getgb.io/" rel="nofollow">https://getgb.io/</a> <a href="/u/hayzeus" rel="nofollow">/u/hayzeus</a> talks? Isn't it perfect for this scenarios?</p></pre>MrCoati: <pre><p>If your project may not be go get'able, i use <a href="https://github.com/skelterjohn/wgo" rel="nofollow">wgo</a>. It sets up a new gopath and the ability to vendor your dependencies. If the project is small or has no dependencies working in your primary GOPATH is the best option/</p></pre>hayzeus: <pre><p>I like gb (<a href="https://getgb.io/" rel="nofollow">https://getgb.io/</a>). Project-based go development. I'm not a huge fan of $GOPATH</p></pre>include007: <pre><p>I am going to play with it and see if it matches.
I don't like this kind of tools that hide how things work normally but.. I will give it a try anyway. thanks</p></pre>Fwippy: <pre><p>If you need per-project dependencies, don't use multiple <code>GOPATH</code>s, just vendor everything. <code>GO15VENDOREXPERIMENT</code> is more than capable of providing you with that isolation, and you can use git submodules (or subtrees or whatever you like) to pin exact versions of the libraries you're using.</p></pre>
