很多服务需要一个配置文件,有一些常见格式:
一个服务用什么格式的配置文件,这个有什么考量吗?用什么比较好?
1
summerwar 51 天前
用啥都可以,你最熟悉啥用啥就行了,都是读取文件,然后把配置拉到代码里
|
2
dreamk 51 天前 1
toml 是目前最先进的配置文件格式
|
3
chendy 51 天前
熟悉啥用啥,不知道用啥就 json
反正逻辑都是一样的,读文件,反序列化,用 |
4
0o0O0o0O0o 51 天前
其实我觉得你可以都用,我就很喜欢同时支持命令行参数, env, yaml 和 json 的项目
|
6
dcsuibian 51 天前
选择 yaml ,选择成功
|
7
kirory 51 天前
还有 .ini, .env
|
8
Hopetree 51 天前
yaml 是目前最好的配置格式,就相当于 markdown 格式一样的存在
|
9
aloxaf 51 天前 1
简单的用 toml ,复杂的用 yaml
json 、xml 这种不是给人读的 CMakeLists.txt 这种属于 DSL 了 |
10
cwcc 51 天前
如果只是读取的话,我个人 yaml 、json 是最推荐的。json 的好处就是兼容性极广,缺点就是不能注释且比较冗余。yaml 的好处就是可读性强且兼容 json ,缺点就是写的话比较混乱。toml 个人觉得有一定门槛但未来可期,ini 太过简单,xml 适合同时读写的复杂结构。
|
11
IvanLi127 51 天前
我选 toml ,如果没复杂的嵌套结构,还是环境变量和 .env 文件比较舒服。如果需要被程序修改的需求,我选 yaml 或 json 。
|
12
flyqie 51 天前 via Android
我个人环境变量、.env 、.ini 写的都比较多,再加上不喜欢那种缩进,一直很偏好 toml
|
13
Trim21 51 天前
yaml 或者 toml
|
14
pb7412221 51 天前
json 是最简单最容易的 唯一的缺点不能写注释 在 json5 中也解决的
|
16
Philippa 51 天前
支持楼上,选择 json 。因为 json 简单易懂,所有人都有相关基础,是最好用的。
toml 有点冷门,很多人不熟悉怎么用。单是先进是不够的。 yaml 就算了吧,你看看 k8s 的那堆文件还有 nindent ,缩进错一丢丢都不行,偶尔字符串偶尔数字,array 表达让人迷惑。 |
17
agagega 51 天前 via iPhone
扩展性:XML>YAML>JSON>TOML
安全性:TOML>YAML>JSON>XML 人类读写:YAML>TOML>JSON>XML 苹果有个叫 pkl 的开源项目,大致相当于给不同的配置文件格式准备的配置文件,你可能会感兴趣 至于 CMakeLists.txt ,即使再怎么吹 modern ,本质上还是一个奇怪的命令式语言,用它还不如用 Lua 或者 Ruby 正经搞个 DSL ,我宁愿写 XML 也不想写它 |
18
kenvix 51 天前 via Android 3
我不知道为什么这么多人喜欢 yaml 。这玩意简直就是一坨屎,我永远不知道当前缩进对的是哪里,这个缩进有没有问题。IDE 也猜不到想表达这块代码的意图位置是哪里。
但凡写过几百行的 yaml 应该和我有同感 |
19
kenvix 51 天前 via Android
如果是几百行甚至上千行以上,有各种复杂逻辑结构的,你就应该用 XML 。明确的作用域和结尾复述对人类心智真的很友好。
如果比较简单,那就 TOML 。 如果极其简单,那就.env yaml 适合 100 行以下规模,超过这个我看见就恶心 另外 hocon 也可以考虑下 |
20
GeekGao 51 天前
|
21
daimaosix 51 天前 via Android
我比较喜欢 yaml
|
22
baobao1270 51 天前
选你用的语言
如果用的 JavaScript ,那就用 js 文件做配置 如果用的 Python ,那么就用 py 文件作为配置 直接 code as configuration |
25
lrh3321 51 天前
手写 toml 不容易犯错误。yaml 在编辑器里写也还好。
|
26
fenglala 51 天前 via iPhone 1
推荐 json5 ,解决了 json 好多弊端,注释什么的都没问题。量大的话不推荐 yaml ,在公司见了上万行的 yaml 格式 git 仓库配置文件,几乎完全不可读,加一行加到哪都很难找。
|
27
Pony69 51 天前
简单 toml ,复杂 yaml
|
28
henix 51 天前
最简单的直接用环境变量
没有复杂嵌套的用 ini 复杂的用 json5 或 json 不推荐 yaml ,这玩意一旦规模上去之后,可读性大幅下降。而且 spec 相当复杂,不同语言实现出来的 yaml parser 可能有功能上的差异,导致同一个配置文件,无法在不同语言之间迁移 |
29
zhuangzhuang1988 51 天前
用 Python ,lua 当配置文件啊。
|
30
lisxour 51 天前
ini toml yaml .env 这几个都是对人类比较友好的,好改很多,结构也比较扁平,json 、xml ,可以存,但是如果经常需要人工修改的场景不建议用
|
32
abcbuzhiming 51 天前
@kenvix 因为 k8s 用 yaml 这东西,而 k8s 用这东西的核心原因是,k8s 工程师写配置文件的量非常大,几万行的配置文件和家常便饭一样。典型的写多读少。对于他们来说,节省几个字符串带来的收益海了去了,所以 yaml 才是这个样子。
但是对但部分其它人来讲,配置文件永远是读多写少。yaml 这种读起来一泡污的语法就一点都不友好了 |
33
abcbuzhiming 51 天前
@GeekGao 这上面写错了,yaml 根本就不易读,人眼的生物特性,更适合横向扫描,而不是纵向位移。这就决定来了 yaml 读起来一点都不友好。而且 yaml 之所以设计成这样就是因为 k8s 的配置代码量非常大,所以少写一个 key 的收益就特别大。yaml 是少见的专门针对写多读少环境的配置语法
|
35
GeekGao 50 天前
@abcbuzhiming 我写了很多年 Python ,我认为 YAML 易读。 这个理由很简单,就像你 “这上面写错了,yaml 根本就不易读” 这句话讲的很轻松那样。
|
36
wheat0r 50 天前
如果配置不是太复杂,toml 挺好用,而且 toml 并不算小众,传统软件的配置文件都是这个风格的,只是名字不叫 toml 。
yaml 的易读程度和屏幕高度正相关,在 16:9 屏幕上就是屎,9:16 屏幕上就好不少。 |
37
abcbuzhiming 50 天前
@GeekGao 我给了理由,不是随便轻松的讲话,人眼的特性就更适合横向扫描。况且你是不是觉得 python 和 yaml 都是有缩进,就觉得这两个玩意一样?你见过 yaml 子项的数量多到可以横跨整个屏幕高度的情况没?
|
38
GeekGao 50 天前
@abcbuzhiming 我还没有遇到感觉很复杂的 case ,我遇到的最复杂的例子是 k8s depolyment 的配置,几百行。
问题是我不需要修改所有配置,所以也感受不到你所述 “横向扫描” 困难的问题。 |
39
abcbuzhiming 50 天前
@GeekGao 我前面说了,yaml 这个东西之所以被 k8s 广泛采用,就是因为 k8s 的工程师动不动就要些几万行的配置文件。在这种数量级下,同样的配置项,少写一个 key 就成为了收益性很高的一件事。所以 k8s 才选了这个格式作为自己的配置文件。
你自己只需要写几百行 k8s 配置,那你一个大类下面有几个子类不得了了,那自然是体会不到这玩意难读的。实际上国外社区已经不止一次抨击过 yaml 作为 k8s 的配置文件“难以阅读”了。就在于我说的,它们说的这种“难读”的 yaml ,一个大类下面子类的数量,多到可以横跨好几个屏幕高度。看着看着眼睛就花了 |
40
GeekGao 50 天前
@abcbuzhiming "一个大类下面子类的数量,多到可以横跨好几个屏幕高度。" 有在线的例子可以分享吗 ? 我去感受一下
|
41
abcbuzhiming 50 天前
@GeekGao 我手上并没有,但是老外的社区说过不止一次这个问题,想来不是空穴来风
|
42
iorilu 50 天前
简单的就是.env, 其他都用 toml
|
45
chinni 50 天前
adguard 的 yaml 配置 我后台里配置了几千条记录 然后打开配置文件 基本没法看
|
46
X_Del 50 天前 1
https://noyaml.com/ 解释的很明白了,为什么不要用 YAML 。
YAML 看起来很简单,实际上非常复杂,很多东西都藏在水下: - YAML 1.1 中 true 和 false 有 22 种表达方式( https://yaml.org/type/bool.html ) - 多行字符串到底有多少种写法( https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines/21699210#21699210 ) - 字符串不严格要求引号,这个例子来自 https://www.arp242.net/yaml-config.html ``` python: 3.5.3 # => 字符串 "3.5.3" postgres: 9.3 # => 数字 9.3 ``` - 由于 YAML 1.2 规范过于复杂,几乎没有一个 YAML parser 能完美地实现 YAML 1.2 ( https://matrix.yaml.info ) |
47
ns09005264 49 天前
bspwm 的配置文件是 shell 脚本,bspwm 本身是 daemon 类型的软件,通过客户端 bspc 与 bspwm 通信实时变更相应的配置。所以可以把一堆 bspc 的操作命令放到 shell 脚本里执行,就相当于配置了。
类似的还有: neovim 是用 lua 语言作为配置 nixos 是用 nix 语言作为配置 |
48
kenvix 49 天前
@GeekGao #35 我写了 8 年 java ( xml 宇宙)、7 年 python (缩进宇宙)、4 年 kotlin ( dsl 宇宙),我认为 yaml 和 python 可读性都是一坨屎。作用域对人类不明确,特别是从外面抄代码时,IDE 根本不能把代码放到正确的意图位置
|
49
GeekGao 49 天前
@kenvix 可读性的定义,不是你 COPY 代码的时候作用域好不好找。可写性指的是编写代码的容易程度。
具有良好可读性的语言可以带来的优势: 更容易理解和维护代码 减少错误的可能性 提高团队协作效率 降低学习曲线 所以,仅凭你的回复,我并认可你对 Python/YAML 可读性的解读(虽然我理解从排版错误的地方 COPY 代码会出错的这个问题) |
50
GeekGao 49 天前
@kenvix 而且,我刚开始写代码的时候,在 Linux 环境下使用 VIM ,Java 这种语言脱离 IDE 根本就无效率可言,更不要说什么可读性了。 况且啊,Python 出现的时间早于 Java 这套体系。
锁进这种设计也是有历史缘故的。90 年代初期,可没有啥好用的 IDE 吧。X11 逐步普及*nix 后才有人搞 GUI 类的编辑器啊。不能脱离历史讲优劣。从 Sun 发布的 Java Workshop 、Eclipse…… 到 Jetbrains 全家桶。这个对工具效率提升的能力跨度,不是隔夜就达成的。 |
51
kenvix 49 天前
@GeekGao #49 确实,我是从 copy 的角度切入举例 yaml 可读性差的的问题,这个切入点可能是不合适的,切到 yaml 可写性极差的问题了。
但是这玩意可读性是真的差,没有高亮括号导致很难瞬间快速定位到当前所在的作用域的范围,必须额外费力观察缩进才能知道当前作用域是哪些 注释掉的 yaml 代码,可读性更是地狱了 |
52
GeekGao 49 天前
@kenvix YAML 早期我也讨厌(更喜欢 JSON 这种通用配置,或者 INI 这种早期我学 Windows 开发的时候的概念) 我是玩了 k8s 后才逐步接受 YAML 的。
关于缩进问题,历史上有太多的争论了,我觉得个人偏好还是不一的,这个没啥科学说法,coding 时开心舒适就好。 |
55
seedhk 48 天前
突然想起有个国产框架叫做 Nutz ,他的配置文件是写在 js 里的,类似:
{ obj:{ xxx:xxx } } |