Best practices for keeping a go project inside a larger monorepo?

agolangf · · 176 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I&#39;m working on a project that keeps a set of services in a single monolithic repo. Each service has it&#39;s own source tree:</p> <pre><code>.git services/ serviceA/ # A Python project serviceB/ # A Java project </code></pre> <p>I want to introduce go to this structure. In real life, there is some wiggle room to change the structure itself, but let&#39;s for the sake of argument say that this Go service <em>must</em> fit into the existing structure, ie:</p> <pre><code>.git services/ serviceC/ # Go project can do what it likes here </code></pre> <p>I&#39;ve thought of two potential options; </p> <p>1) simply symlink serviceC into $GOPATH; this seems horrible and likely to cause insane edge cases</p> <p>2) embed a dedicated $GOPATH structure at serviceC and append that to $GOPATH, ie:</p> <pre><code>.git services/ serviceC/ bin pkg src/ ??/servicec/main.go </code></pre> <p>This seems less horrible; but I&#39;m concerned the <code>go</code> tool will hiccup on trying to treat first-level directories under <code>src</code> as domains.. and writing a gitignore that excludes everything under <code>src</code> other than my project seems icky..</p> <p>Suggestions? Are there any writeups of doing this?</p> <hr/>**评论:**<br/><br/>bilus: <pre><p>Option C: Just go get</p> <p>This makes for lengthy import paths but maybe you can live with it. If not, set up a vanity alias at your domain.</p></pre>twetewat: <pre><p>Digital ocean has a good writeup of this: <a href=""></a></p></pre>sxan: <pre><p>You&#39;re in production, and it&#39;s too early for production, but <a href="" rel="nofollow">vgo</a> solves this. It lets you put your code anywhere.</p> <p>It&#39;s from Russ Cox so has a high chance of acceptance, and I&#39;ve been using it successfully in lightly shared projects at work; it&#39;s still a proposal under development, though, do caveat lector.</p></pre>titpetric: <pre><p>You don&#39;t need to symlink, there&#39;s a few options:</p> <ul> <li><a href="" rel="nofollow">goenv</a></li> <li>docker, (<code>docker run -it --rm -v $PWD:/go/src/... golang:alpine go build/run/etc.</code>)</li> <li>have the build toolchain in a docker image (using a CI that you can run locally, like <a href="" rel="nofollow">codeship</a> &#34;jet&#34; tool)</li> </ul> <p>Generally, at least docker/CI approach doesn&#39;t require you to set up a GOPATH structure, and it&#39;s possible to set up vanity aliases so you can have whatever import path you like to your app.</p> <p>Not sure your comment about <code>src/</code> is relevant. You would only have your project under src, and for whatever dependencies you pull in, you should be using vendoring by now (dep, recently vgo). Generally it&#39;s advised to commit the vendor/ folder, but because of licensing restrictions and such, you might have to pull them on demand (vgo supposedly handles something about licenses something something, didn&#39;t read it very carefully, but if you care about which packages you include because of their licenses, you should be using vgo aparently, it&#39;s the current thing).</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

176 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传