<p>I've been developing a few tools using go that might use configuration files, but I've yet to discover what is the consensus on which one.</p>
<p>I saw that the standard lib has support for XML and JSON, but dep is using TOML, and also its filename has its first letter as uppercase, so I feel kind of lost as to which patterns to follow.</p>
<p>tl;dr: RoR uses YAML, Node.js uses JSON, Go uses ...?</p>
<hr/>**评论:**<br/><br/>peterbourgon: <pre><p>There is no language standard, nor should there be, really. Choose the format whose compromises are the best fit for your application.</p>
<p>edit: just don't choose YAML ;)</p></pre>goomba_gibbon: <pre><p>XML it is then! :)</p></pre>jeffrallen: <pre><p>Downvote for XML, upvote for funny = no vote.</p></pre>goomba_gibbon: <pre><p>I'm not sure if there is a convention really. I don't want to sound rude, but does it really matter?</p>
<p>I personally really like toml because it's a bit more human-readable, unlike XML. I used <a href="https://github.com/BurntSushi/toml" rel="nofollow">https://github.com/BurntSushi/toml</a> without any problems.</p>
<p>Good luck. </p></pre>pomone0088: <pre><p>Didn't sound rude, don't worry.</p>
<p>It does matter because if (hopefully when) I have to hire more Go developers, if a consensus for this exists, it is more likely that they will already also know how to deal with it.</p>
<p>And yes, I've been leaning towards TOML but not for the same reason. I will probably use it because dep also uses it and it is on its way to become an official tool, meaning that if it is preferred by an official tool, it, probably, is doing something right.</p></pre>goomba_gibbon: <pre><blockquote>
<p>It does matter because if (hopefully when) I have to hire more Go developers, if a consensus for this exists, it is more likely that they will already also know how to deal with it.</p>
</blockquote>
<p>Perhaps but I would expect developers to already know, or be able to learn, any <em>sane</em> config file formats. Some might have quirks but they aren't that complex. </p></pre>sxan: <pre><p>One thing TOML has going for it is that, at the moment, it is the config syntax choice for dep, the candidate for the official dependancy management tool. If that all sticks, TOML would likely make it into the stdlib.</p>
<p>It isn't much, but it is a thin edge.</p></pre>goomba_gibbon: <pre><p>Definitely a point in TOMLs favour but does the use in dep automatically mean it will be added to the stdlib?</p></pre>peterbourgon: <pre><p>No, it definitely doesn't.</p></pre>goomba_gibbon: <pre><p>Thanks. The impression I get is that the go team would like to keep the stdlib as concise as possible (which I think makes sense).</p>
<p>If community packages aren't suitable then potentially the go team could create a TOML package that lives outside the stdlib.</p>
<p>The dep tool currently uses <a href="https://github.com/pelletier/go-toml" rel="nofollow">https://github.com/pelletier/go-toml</a> and why not? </p></pre>sxan: <pre><p>Maybe not, but if dep gets rolled into the standard toolset, and dep uses TOML config files and therefore has a TOML parser built in, it'd be a pretty strong case to include the TOML library in stdlib. It'd need to be in there somewhere to build dep, but, yeah, they could have the library built into the toolset and yet not accessible to developers.</p></pre>fortytw2: <pre><p>I think it's highly unlikely for <code>dep</code> to be rolled into the standard toolset as is - <code>dep</code> is an experiment, as far as I'm aware.</p>
<p>relevant ML bits - <a href="https://groups.google.com/d/msg/golang-nuts/PaGu2s9knao/Bq4vmFh7AgAJ" rel="nofollow">https://groups.google.com/d/msg/golang-nuts/PaGu2s9knao/Bq4vmFh7AgAJ</a></p></pre>dmikalova: <pre><p>I find Cobra and Viper to be very nice to use. They're idiomatic and used by some of the big names in the community.</p></pre>Hexodam: <pre><p>can easily recommend Viper</p></pre>jeffrallen: <pre><p>Given that the Go world doesn't have a standard for this, look at the tools you are using alongside this new thing and make the config file the same. Thus if your ops guys already are doing YAML for their Docker Compose definitions, use YAML. (Which is gross, BTW.)</p>
<p>-jeff</p></pre>
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码`
- 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传