What is your Go dev environment like, and are you most doing with Go?

<p>Hi, this topic is simple, I&#39;m learning Go and I would like to know, how you guys are structuring your projects and where do you place them on your system, do you add a GOPATH for each project?</p> <p>The other question is, what are you developing with Go?</p> <hr/>**评论：**<br/><br/>sambull: <pre><p>I use a single $GOPATH set to $HOME/go. </p> <p>I then use $HOME/go/src to develop out of. </p> <p>So my package might be in.. $HOME/go/src/gitlab.com/username/packagerepo</p> <p>(I would have probably used go get to grab bare repo i created) </p></pre>014a: <pre><p>Our team has adopted a style similar to <a href="https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a-scalable-repo/" rel="nofollow">how DigitalOcean organizes their code</a>, but have modified it a bit to support using <code>dep</code>.</p> <p>The root of our monorepo is a <code>GOPATH</code> workspace, organized like:</p> <pre><code>src |- company |- service1 |- lib |- vendor Gopkg.toml Gopkg.lock Makefile </code></pre> <ul> <li>All <code>dep</code> commands are executed within the <code>src/company</code> directory; we have an alias set up on all our developer machines to make this seamless. </li> <li>The <code>Makefile</code> contains all the build steps necessary to build every project. </li> <li><code>service1</code> and like folders are each vertical project; all of them main packages, most of them web services, some of them cli tools. All of these folders have a <code>MAINTAINERS</code> file which contains email addresses of the people to contact for that specific project.</li> <li><code>lib</code> contains code and resources shared between services, including grpc protos. </li> <li><code>vendor</code> contains dependencies shared between every project, and it isn&#39;t committed to git. </li> </ul> <p>There are a few reasons why we&#39;ve found this to be a good setup:</p> <ul> <li><p>Monorepos have their downsides, but being able to track every change to our backend in one repo with no additional tooling (aka straight on github) is huge. It also makes our build process easier; no need to worry about our CI systems being authorized to access private repositories for shared code, because everything is in one repo.</p></li> <li><p>Sharing external dependencies can suck, but forcing all of the projects to reference the same dependencies usually makes us better about keeping them and our referencing code up to date. Most of the time, project code which relies on an external dependency is &#34;proxied&#34; through shared code in <code>lib</code>, meaning its just a single point of update for every project and we control the APIs our projects use in accessing those external dependencies.</p></li> <li><p>Import paths are shorter; just <code>company/lib/whatever</code>. </p></li> </ul></pre>qu33ksilver: <pre><p>Use single $GOPATH. Arrange your code like so - <a href="https://golang.org/doc/code.html#Workspaces" rel="nofollow">https://golang.org/doc/code.html#Workspaces</a></p></pre>usualdev: <pre><p>New to go as well, I use one path $HOME/go and put all apps under src. I use Goland IDE and I love it. </p></pre>caseynashvegas: <pre><p>I use a single GOPATH, and I&#39;ve taken the habit of organizing all my source code into it it. I use dep as a dependency / package management solution and I no complaints. I actually use $Home/code as my GOPATH, since I don&#39;t limit my repos to Go, I figured $HOME/go might be a bit odd. I use VSCode as my primary editor for everything these days.</p></pre>maximch: <pre><p>I use gvm to manipulate different versions of go and different environments for each project:</p> <p><a href="https://github.com/moovweb/gvm" rel="nofollow">https://github.com/moovweb/gvm</a></p></pre>