<p>Hello, I am coming from the Python community where I've found machine set-up to be absolutely vital to a productive error free environment. I am excited to give Go a proper run... I have a few questions:</p>
<ul>
<li>Workspapces from here: <a href="https://golang.org/doc/code.html">https://golang.org/doc/code.html</a></li>
</ul>
<p>With virtualenv's I have a nice way to conceptually and physically keep projects separate. I have a separate virtualenv for most projects and keep code for each project in a separate directory.</p>
<p>How do I conceptually and physically keep projects "isolated" with Go? Should I keep projects in different folders under <strong>src</strong>? libraries in <strong>pkg</strong> (including 3rd party github libs)? What is the idiomatic way to organize my files/dirs/projects for Go?</p>
<p>The docs aren't super clear for me here. I'd like to get started on the right foot rather than fight with my set-up like I did with Python, until I switched to Anaconda distribution. </p>
<ul>
<li>Gopath and more from same source as above</li>
</ul>
<p>I am not entirely clear how the GOPATH works and I am not understanding it conceptually. For example, The doc linked says Gopath for the workspace needs to be set apart from the Go installation. This is related to the question above because, it seems like I will need to keep just one workspace unless I want to fiddle with my paths all the time... or not.</p>
<p>Further, how does the Gopath interact with the rest of my path variables, e.g. Python and Java from within my shell and/or editors. Should I append the Gopath to the path variables as they are right now in my .zshrc or do I need to have a completely different export statement in my .zshrc? </p>
<p>I think once I have these ideas sorted out conceptually, I will be in a much better place to dive into the language. I had to do the same thing with Python and Java... once I groked the system level interaction, learning the language was a lot easier. </p>
<p>I am a OSX user. I use Pycharm, Vim and Atom... </p>
<hr/>**评论：**<br/><br/>captncraig: <pre><p>Most go devs will use a single gopath on their system. You could potentially "isolate" projects with multiple gopaths, but that can get tricky, and people generally don't.</p>
<p>My gopath is ~/gopath. I add ~/gopath/bin to my path. All my code goes in ~/gopath/src/github.com/myname/projectname. Any library code also gets put in ~/gopath/src when you download it with <code>go get</code>.</p>
<p>Pretty much every person new to go wants to fight this setup. They almost all end up accepting it because it is just easier than fighting it. </p></pre>monkmartinez: <pre><p>Thank you!</p>
<p>I hope I didn't come off as fighting this step. I just want to understand the why of it. I definitely don't want to do anything tricky, I always strive for simplicity.</p>
<p>So if I understand your setup, this is a rough approximation of your structure:</p>
<p><code>~/gopath/src/github.com/myname/project1</code></p>
<p><code>~/gopath/src/github.com/myname/project2</code></p>
<p>and so on... Then the libraries end up looking like this:</p>
<p><code>~/gopath/src/lib1</code></p>
<p><code>~/gopath/src/lib2</code></p>
<p><code>~/gopath/src/lib3</code></p>
<p>So the libraries are intermixed with the project folders inside the src dir?</p>
<p>What does you path look like inside your shell (bashrc, .zshrc, etc.) config? E.g. my .zshrc == <code>export PATH="/Users/mm/anaconda/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:"</code></p>
<p>Really appreciate your response.</p></pre>weberc2: <pre><p>While I have one $GOPATH for my whole system, it's perfectly valid to keep one $GOPATH per project, giving you something similar to your virtualenv solution.</p>
<p>If you do this AND you care about versions, it's idiomatic to put that stuff into a /vendor directory (read up on golang vendoring best-practices; I don't do this and can't give advice) and commit that directory to version control (but make sure your .hgignore or .gitignore is ignoring .svn, .hg, and .git directories so you're not checking in the entire history of all of your dependencies). You will probably also want to keep track of your versions of each package, either in a central dependencies file or drop a VERSION file in each vendored dependency. There are tools like <code>godep</code> to assist you with vendoring, but again, you'll want to look up best-practices because they've evolved considerably since I last investigated.</p>
<p>Alternatively, if you don't care about versions, then you can set up your version control system's ignore rules to ignore other dependencies altogether (you'll just be building against the latest version of your dependencies all the time).</p>
<p>Also, an alternate project-focused build tool is gaining traction, and might be worth looking into: <a href="http://dave.cheney.net/2015/05/12/introducing-gb" rel="nofollow">http://dave.cheney.net/2015/05/12/introducing-gb</a></p></pre>monkmartinez: <pre><p>Bookmarked Dave Cheney... and I've read a bunch there. Thank you for the response.</p></pre>Fwippy: <pre><p>Yep, the libraries will be under things like <code>$GOPATH/src/bitbucket.org/someotherguy/lib3</code>. Running <code>go get</code> will automatically put them in the right spot, and you don't need to worry about it it all. In your code, you'll import it like <code>import "bitbucket.org/someotherguy/lib3"</code>, and everyone who gets your code will know where to find its dependencies.</p></pre>monkmartinez: <pre><p>You were right, I didn't need to worry about it at all. Thank you for the response.</p></pre>kaeshiwaza: <pre><p>Coming from python, i use one GOPATH by project, like i did with virtualenv.
I often mix python and go in the same project, then i have
myproject/py
myproject/go (=GOPATH when i work on myproject)</p>
<p>With every projects in the same GOPATH i don't know how you deal with different versions of the same lib, how you know which project use which lib. If you remove a project you have to check which lib you can remove...
If you use the new /vendor option, finally you reinvent GOPATH, i don't understand...
But i must be wrong if nobody do like that !</p></pre>lapingvino: <pre><p>The idea is that you should always be compatible with the latest version of the code, you shouldn't easily break compatibility and if you rely on older versions, you should maintain that yourself (hence the vendor directory for that case).</p></pre>kaeshiwaza: <pre><p>I follow this rule also, but i don't see how it's easier with /vendor than a GOPATH per project.</p></pre>lapingvino: <pre><p>with /vendor you make sure that people who go get your project will have working code (you check in the code the way it is you use it). if you don't do this but you do rely on older versions of some code, when other people go get it they will just see that your code is not working... you need to start documenting which versions of what you need, without a guarantee that that version will always be available. the vendor path also makes sure that you can e.g. go back to mainstream if something there is fixed etc, because you keep using the same import path, the vendor version just takes preference.</p></pre>
