How do I setup my GOLANG variable so it plays nice with other repositiories?

<p>Hi, I&#39;m a windows user trying to get Go to behave with the other languages in my computer.</p> <p>The docs specify to set <code>GOPATH=%USER%/work/</code> or <code>/work/go</code>. This assumes that all projects must either be created in the work directory or indicates that go code doesn&#39;t play nice with other repositories. I often like to spawn random projects on my desktop, and don&#39;t want to have my coding projects segregated by language. I tried installing some intellisense tools for atom and sublime and they all want a gopath setup before they can run. Pointing it to my first go tutorial project has led it to go fetch a bunch of junk in a disorganized way, putting them in a bin and src folders in the project. Creating a second project means pointing my gopath to the second project and having it download all my autocompletion tools there again.</p> <p>I&#39;m trying to emulated a python installation where common tools are installed in root and project specific dependencies are installed in the virtualenvs. Is it possible to install go in a way where it can behave this way? Also so that looks only at the current and global environment for dependencies, rather than a glob behavior: &#34;The GOPATH environment variable is used to specify directories outside of $GOROOT that contain the source for Go projects and their binaries.&#34; The desired workspace would look like this:</p> <pre><code>c:\unix\python35 ...global python stuff here like virtualenv... c:\unix\go ...global go stuff here like all the autocomplete tools... %user%\repos\ APythonProject\ venv\ src\ .git\ AnotherPythonProject\ venv\ src\ .git\ AGoProject\ bin\ src\ SPECIFIC TO THIS PROJECT .git\ AnotherGoProject\ bin\ src\ SPECIFIC TO THIS PROJECT .git\ AC#Solution\ AC#project\ packages\ AnotherC#Project\ packages\ .git\ </code></pre> <p>If I severely misunderstood how the gopath works, could someone enlighten me? Thanks</p> <hr/>**评论：**<br/><br/>PsyWolf: <pre><p>The GOPATH has a very specific layout and it does not match what you want. Specifically, I wouldn&#39;t recommend mixing code from other languages into your GOPATH. That would be like putting non-python code in your PYTHONPATH. It might work, but it would be weird. The way I see it, you have 2 options here:</p> <p>A) Embrace the GOPATH as it was designed. If you can explain to us why you think you need your python projects mixed in with your go projects, then we may be able to find an alternative that lets you use the GOPATH as it was intended. If your need for this layout is simply preference and not a technical requirement, then put that preference aside for a while and learn the language as it was designed to be used before you try to do something non-standard. Down path A lies less surprises and better community support.</p> <p>B) Forsake the GOPATH. This is the road less traveled and we may not be able to help you as much with it, but technically, only the go command line tool requires the GOPATH. The language itself doesn&#39;t. There is an alternative to the go tool called <a href="https://getgb.io" rel="nofollow">gb</a> that may be a better fit for you.</p> <p>P.S. In case it wasn&#39;t clear, I strongly recommend option A.</p> <p>edits: lots of small additions to improve clarity</p></pre>dlsniper: <pre><p>I keep all my code in GOPATH now, it just makes a lot more sense to find it. Also, having a directory that holds all the repos in one places basically does that anyway. And it&#39;s oh so convenient to do a go get on any repo and have it cloned in the right place. </p></pre>PsyWolf: <pre><p>Interesting, it&#39;s good to know that the go tool ignores other languages as expected. I wonder what (if any) performance impact that has on tools like goimports and guru that have to look through everything in your gopath.</p></pre>dlsniper: <pre><p>This is my GOPATH <a href="https://gist.github.com/dlsniper/5eeb713fd9b00cd8d40e#file-cloc-txt" rel="nofollow">https://gist.github.com/dlsniper/5eeb713fd9b00cd8d40e#file-cloc-txt</a> and I don&#39;t think I&#39;ve seen any problems with it. Intellij gets a bit grumpy from all the Javascript at times but I don&#39;t have problems on a 16gb, 8 core i7 machine.</p></pre>g2909532: <pre><p>It just seems weird that for every other language out there, I can clone the source from github/gitlab/bitbucket to my repos folder, acquire its dependencies and build the project in place. Having a gorepos/ for go repos and repos/ for all the other languages just seems weird. Having go get scan/index through thousands of files in version control ignored folders such as debug/ and cache/ in order to resolve dependencies of 1 project is also weird. I often clone random repos just to observe the code, so my repos folder has a &#34;large&#34; amount of files.</p> <p>edit: gb is probably what I&#39;m looking for, after looking at their rationale and faq page. I don&#39;t like how the go community is hogging the 2 letter namespace for shell commands though.</p></pre>PaluMacil: <pre><p>I&#39;ve heard of people having success with using sym links to get full control over where the code for the project resides, so perhaps that could work for you without the need to use gb (which I haven&#39;t heard of, but perhaps it&#39;s well maintained and also a great choice). I haven&#39;t tried any workarounds myself. I used to want my folder structures to be standardized too, but as I learned more languages, I gave up since there is so much variance inside the projects anyway. It is an opinionated choice but doesn&#39;t really affect my workflow in any way.</p></pre>Sphax: <pre><p>Why is it weird ? It&#39;s just been designed that way. I&#39;d suggest to not fight the language/tools because you&#39;ll always have problems that way. Use a single GOPATH for all your Go code and be done with it.</p> <p>Also, what do you mean about go get ? </p></pre>PsyWolf: <pre><p>If the go authors liked the way that every other language did things, there would be no go language. If programmers liked the way that every other language did things, there&#39;d be no adoption. Clearly, &#34;because other languages do it that way&#34; isn&#39;t always enough justification for a feature.</p> <p>Many languages have a path that the tooling uses to look for dependencies that is very much like the GOPATH (PYTHONPATH, LIBRARY_PATH, etc). The difference is that those languages see your libraries as very different things from your applications. They mandate where you libraries should be installed, but they let your application code live anywhere. That design decision adds some complexity to the build chain that can be confusing at times. </p> <p>On the other hand, the GOPATH treats library packages and application packages in nearly the same way. This makes the behavior of the build tools more obvious and less magical. &#34;go get&#34; doesn&#39;t have to know if a repository holds and application or a library to know where to download it to. It gets particularly interesting when a repository is both a library AND an application. The tool would have to ask you how you were going to use it before it knew where to drop it.</p> <p>Long story short, the GOPATH will make your life easier if you let it. You&#39;re welcome to disagree with me AFTER you&#39;ve tried it out for a while. Dismissing the GOPATH without giving it a shot is doing yourself a disservice.</p></pre>