Third party dependencies seems like a mess. Am I missing something?

<p>I&#39;m doing a project where there&#39;s a microservice in Go. The project is basically one big project(in intellij IDEA), in one git repository, with different modules - a pretty normal project structure, I reckon. The reasoning for this is that i want to run several services at once, and I don&#39;t want to open 3x different IDEA projects.</p> <p>However, it appears to me that for Go to be able to <code>go get</code> a third party dependency - in my case, <code>&#34;golang.org/x/crypto/acme/autocert&#34; </code>, my Go project has to be in the GOPATH? Is there any way to circumvent it? It seems like a huge liability and annoyance to developers.</p> <p>Can I &#34;manually&#34; download the package in my &#34;local&#34; project and just run it from there? Or is this issue solved in other ways?</p> <hr/>**评论：**<br/><br/>shovelpost: <pre><ul> <li><a href="https://golang.org/cmd/go/#hdr-Vendor_Directories" rel="nofollow">Vendoring</a></li> <li><a href="https://github.com/golang/dep" rel="nofollow">dep</a></li> </ul></pre>Franke123: <pre><p>Yeah your project has to be in your gopath. How is that a big annoyance or liability for developers?</p></pre>cbll: <pre><p>If a teammember just wants check out the project, build the Go service and run it without ever developing on it?</p></pre>epiris: <pre><p>If they never want to develop on it then they do not need to build from source. Build binaries, distribute Docker / Docker-compose file or even a makefile can build and run a Go binary with no problem. If they want to build from source they need to play by the sources rules, as they do for any other language.</p></pre>drvd: <pre><p>If they are unwilling or incapable of doing <code>GOPATH=/tmp/yourproject go get your.projets/import/path</code> (or your project isn&#39;t go getable) then they can check it out to the default GOPATH of $HOME/go. So dead simple, so un-annoying compared to anything else. Where&#39;s the problem?</p></pre>cbll: <pre><p>The problem is that it&#39;s a hassle compared to doing a git pull to a Java project and build everything automatically with Maven/Gradle. I like Go but this is the only quirk I&#39;ve disliked so far. Plenty of people seem to agree on the PR&#39;s on github. </p></pre>drvd: <pre><p>You must be joking. Setting up Java and Gradle is a much bigger hazel than exporting one single environment variable if you do not want to use the default. Doing a git clone ...&amp; mvn verify is simpler only after setting up Java and Maven. Please do not compare apples to sea urchins.</p></pre>r-_3: <pre><blockquote> <p>Setting up Java and Gradle </p> </blockquote> <p>Actually no because you don&#39;t even need gradle to build a project that uses gradle file, only the JVM.</p></pre>deranjer: <pre><p>Currently I would NOT recommend fighting GOPATH. I tried it, by setting up some scripts in my IDE to copy files back and forth from GOPATH, but that was clunky. There is some talk of GOPATH changes coming in the next version of go (June 2018 I think?) but no guarantees. </p> <p>If you really DO want to fight GOPATH, try out <a href="https://github.com/GetStream/vg" rel="nofollow">VG</a> and <a href="https://github.com/golang/dep" rel="nofollow">dep</a>, which combine to provide something very similar to python&#39;s virtualenv, if you are familiar with that.</p></pre>meta_leap: <pre><p>Sounds like your IDE were unduly limited if it couldn&#39;t open/store/manage projects (or multi-project work-spaces) <em>anywhere you want</em> (including your <code>$GOPATH</code>)? Surely that isn&#39;t the case!</p></pre>cbll: <pre><p>Using Intellij idea with goland plugin. It tries to install it for me but it never goes through.</p></pre>