Idiomatic way of handling local libraries?

<p>Is there an idiomatic way to handle local libraries to be included only in your source tree?</p> <p>i.e. A library on github is going to live at </p> <pre><code>$GOPATH/src/github.com/user/library </code></pre> <p>but I have say a half dozen libraries (auth, controller, etc) that I&#39;m splitting out into their own small packages. So far I&#39;m using local/package name so they look like this</p> <pre><code>$GOPATH/src/local/package </code></pre> <p>and then importing like this</p> <pre><code>import( &#34;local/package&#34; ) </code></pre> <p>but I&#39;m curious if this is a general best practice if you&#39;re checking in src and pkg?</p> <hr/>**评论：**<br/><br/>alaskacodes: <pre><p>I wouldn&#39;t call this &#34;vendoring&#34;, necessarily, so much as a question on how to arrange a project with potentially multiple binaries and a lot of shared but very project-specific code. If external dependency stability and maintenance aren&#39;t as much of a concern for you, and you&#39;re absolutely sure you can&#39;t/won&#39;t use your shared library code anywhere else, you could always arrange your project like this:</p> <pre><code>$GOPATH/src/github.com/user/ project/ mylib/ mylib.go myotherlib/ myotherlib.go bin/ bin1/ main.go bin2/ main.go </code></pre> <p>Which is a fairly common way to do things, and you&#39;ll see it a lot. This way, your imports still make sense and you can share code. The only note of caution is that it will be more difficult to split off any libraries into their own repos and maintain their history if you do decide to make them more generally available. Not impossible, necessarily, but <a href="http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/" rel="nofollow">a bit more of a pain</a>.</p> <p>I&#39;d also recommend you check out <a href="http://getgb.io/" rel="nofollow">gb</a> for building larger projects and see if you like it. It might seem like overkill at first, but you guarantee that your code will always build, regardless of changes in APIs or (worst case) disappearing dependencies. With the vendor plugin, however, you can easily test out putative changes or new APIs without fear of having broken code checked in.</p></pre>FIuffyRabbit: <pre><p>I think you want <a href="https://medium.com/@freeformz/go-1-5-s-vendor-experiment-fd3e830f52c3" rel="nofollow">vendoring?</a></p></pre>ettupaca: <pre><p>I ended up moving auth to the top level and putting my various submodules underneath it. But yeah, basically reinventing vendoring :V</p></pre>daveddev: <pre><p>This may be what you are referring to. I&#39;m not sure of it&#39;s current status in the language, but will post back here if I become aware of it.</p> <p><a href="https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit?pli=1" rel="nofollow">https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit?pli=1</a></p></pre>