处理Go程序的配置参数的首选方法是什么(在其他上下文中可能使用属性文件或ini文件的那种东西)?
当前回答
我用golang写了一个简单的ini配置库。
https://github.com/c4pt0r/cfg
gorroutine安全,易于使用
package cfg
import (
"testing"
)
func TestCfg(t *testing.T) {
c := NewCfg("test.ini")
if err := c.Load() ; err != nil {
t.Error(err)
}
c.WriteInt("hello", 42)
c.WriteString("hello1", "World")
v, err := c.ReadInt("hello", 0)
if err != nil || v != 42 {
t.Error(err)
}
v1, err := c.ReadString("hello1", "")
if err != nil || v1 != "World" {
t.Error(err)
}
if err := c.Save(); err != nil {
t.Error(err)
}
}
=================== 更新 =======================
最近,我需要一个INI解析器与节支持,我写了一个简单的包:
github.com/c4pt0r/cfg
你可以像使用"flag"包一样解析INI:
package main
import (
"log"
"github.com/c4pt0r/ini"
)
var conf = ini.NewConf("test.ini")
var (
v1 = conf.String("section1", "field1", "v1")
v2 = conf.Int("section1", "field2", 0)
)
func main() {
conf.Parse()
log.Println(*v1, *v2)
}
其他回答
只使用标准的go标志和iniflags。
去的旗帜
进口“国旗” var nFlag =标志。Int("n", 1234, "标志n的帮助信息")
iniflags
主要包 导入( “国旗” ... “github.com/vharitonsky/iniflags” ... ) var ( Flag1 =旗帜。字符串("flag1", "default1", "Description1") ... flagN = flag。Int("flagN", 123, " description ") ) Func main() { iniflags.Parse() //用它代替flag.Parse() }
标准go标志有以下好处:
惯用。 使用方便。标志可以很容易地添加并分散在项目使用的任意包中。 标志对默认值和描述有开箱即用的支持。 标志提供带有默认值和描述的标准“帮助”输出。
标准go标志的唯一缺点是,当你的应用程序中使用的标志数量过大时,会出现管理问题。
Iniflags巧妙地解决了这个问题:只需修改主包中的两行,它就神奇地获得了从ini文件读取标志值的支持。ini文件中的标志可以通过在命令行中传递新值来覆盖。
参见https://groups.google.com/forum/#!topic/golang-nuts/TByzyPgoAQE获取详细信息。
对于更复杂的数据结构,我通常使用JSON。缺点是,您很容易以一堆代码来告诉用户错误在哪里、各种边缘情况和其他情况。
对于基本配置(api密钥,端口号,…)我在使用gcfg包时运气非常好。它基于git配置格式。
从文档中可以看到:
示例配置:
; Comment line
[section]
name = value # Another comment
flag # implicit value for bool is true
结构:
type Config struct {
Section struct {
Name string
Flag bool
}
}
读取它所需的代码:
var cfg Config
err := gcfg.ReadFileInto(&cfg, "myconfig.gcfg")
它还支持切片值,因此您可以允许多次指定一个键和其他类似的好特性。
像本文一样使用toml读取配置文件
https://github.com/spf13/viper和https://github.com/zpatrick/go-config是非常好的配置文件库。
我尝试了JSON。它工作。但我讨厌必须创建我可能要设置的确切字段和类型的结构体。对我来说,这是一种痛苦。我注意到,我能找到的所有配置选项都使用这种方法。也许我在动态语言方面的背景让我看不到这种冗长的好处。我制作了一个新的简单配置文件格式,以及一个更动态的库来读取它。
https://github.com/chrisftw/ezconf
我对围棋世界很陌生,所以这可能不是围棋的方式。但是它很有效,非常快,而且使用起来超级简单。
Pros
超级简单的 更少的代码
Cons
没有数组或Map类型 非常平面的文件格式 非标准的conf文件 它有一个内置的小约定,我现在在围棋社区普遍不赞成这个约定。(在config目录中查找配置文件)