关于编程语言:KCL-语言-v045-版本发布-更好的编写便利性改进稳定性体验提升与多平台支持

简介

KCL 团队很快乐地发表 KCL v0.4.5 版本当初曾经可用！本次公布次要为 KCL 语言编写便利性和稳定性晋升，错误信息改良以及更多平台包含 windows 版本反对以及更多下载方式反对。在 KCL v0.4.5 版本中，用户能够通过编写更少的 KCL 代码打消更多的配置模版；在新版本中提供了初步的 KCL Playground 反对可用于在线免装置编写并运行 KCL 代码；此外此次更新还蕴含多项编译器报错信息优化和谬误修复。

您能够在 KCL v0.4.5 发布页面 或者 KCL 官方网站 取得 KCL 二进制下载链接和更多具体公布信息。

KCL 是一个开源的基于束缚的记录及函数语言，冀望通过成熟的编程语言技术和实际来改良对大量繁冗配置和策略的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简略的逻辑编写，以及更快的自动化集成和良好的生态延展性。

本文将会介绍 KCL v0.4.5 版本的更新内容以及 KCL 社区的近期动静。

语言更新

KCL 语言编写便利性改良

反对 Schema 非空属性惰性校验

在之前的 KCL 版本中，咱们曾经反对了 schema 属性相互援用（蕴含继承）以及 check 校验表达式的惰性求值与校验能力，在此次版本更新中，咱们反对了更多的 schema 惰性求值能力: Schema 属性非空惰性校验。比方对于下述的 KCL 的代码：

schema Spec:
    id: int
    value: str

schema Config:
    name?: str
    spec: Spec = Spec {id = 1}   # 在 KCL v0.4.5 版本之前，这个语句会报属性非空谬误，v0.4.5 版本之后，反对 Schema 非空属性惰性校验能力

config = Config {spec.value = "value"}

在 v0.4.5 之前的 KCL 版本中，间接执行上述代码会在 schema Config 语句块的 spec: Spec = Spec { 处抛出一个 spec 的 value 属性不能为空的谬误，因为在该处只对 spec 的 id 属性赋值为 1，而没有对 spec 的 value 属性赋值。

在 KCL 的 v0.4.5 版本更新后，咱们反对了 schema 属性的惰性非空校验能力之后会防止这个谬误的抛出，即当在 config 属性的 spec.value = "value" 与 spec.id = 1 合并之后才会递归地对 config 的所有属性进行非空查看，此时 spec 属性的所有值是被残缺赋值的 (spec 的 id 字段的值为 1, value 字段为 "value"，)，不会抛出必选属性字段为空谬误。

因而在 v0.4.5 版本之后，执行上述 KCL 代码，咱们会失去如下所示的残缺 YAML 输入:

config:
  spec:
    id: 1
    value: value

反对配置块属性相互援用以打消更多的配置模版

在 v0.4.5 之前的版本中，KCL 尚未反对配置块外部的属性相互援用，导致在某些场景中会须要定义额定的配置变量或者模版来进行援用，会产生较多的配置模版和反复代码，比方对于如下所示的 KCL 代码：

name = "app-name"
data = {
    name = name
    metadata.name = name  # `metadata.name` 不能间接援用 `data` 外部的 `name` 属性
}

data 配置块的 metadata.name 属性不能间接援用 data 外部的 name 属性，须要额定定义一个全局变量 name 进行援用。

而在 KCL 的 v0.4.5 版本更新后，咱们反对了配置块属性相互援用的个性，能够用于打消更多的配置模版，比方如下所示的 KCL 代码：

data = {
    name = "app-name"
    metadata.name = name  # 间接援用 `data` 配置的 name 属性
}

data 配置块的 metadata.name 属性能够间接援用 data 外部的 name 属性而无需定义额定的全局变量。

执行上述 KCL 代码能够取得如下 YAML 输入:

data:
  name: app-name
  metadata:
    name: app-name

上面是一个更简单的例子

name = "global-name"
metadata = {
    name = "metadata-name"
    labels = {
        "app.kubernetes.io/name" = name  # 间接援用 `metadata.name`
        "app.kubernetes.io/instance" = name  # 间接援用 `metadata.name`
    }
}
data = {
    name = name  # 援用全局的 `name` 变量
    metadata = metadata  # 援用全局的 `metadata` 变量
    spec.template.metadata.name = metadata.name  # 援用 `data` 外部的 `metadata` 变量
}

执行上述代码能够取得如下 YAML 输入:

name: global-name
metadata:
  name: metadata-name
  labels:
    app.kubernetes.io/name: metadata-name
    app.kubernetes.io/instance: metadata-name
data:
  name: global-name
  metadata:
    name: metadata-name
    labels:
      app.kubernetes.io/name: metadata-name
      app.kubernetes.io/instance: metadata-name
  spec:
    template:
      metadata:
        name: metadata-name

留神：以后 KCL 版本尚未反对配置块外部属性后向援用以及跳过外部作用域间接援用全局变量，须要将被援用的属性书写在配置援用处的后方

KCL 语言新增性能

字符串 format 成员函数反对索引格式化

在 KCL v0.4.5 版本更新后，KCL 反对了相似 Python 字符串 format 成员函数在 {} 格式化块中应用 <format_ele_index>[<index_or_key>] 索引标记款式对列表和字典类型的 KCL 变量进行格式化。其中

• <format_ele_index> 示意须要须要序列化列表和字典类型元素的索引
• <index_or_key> 示意对应列表和字典类型元素的列表子元素索引或者字典子元素键值

比方对于如下的 KCL 代码

# 0[0] 示意取 ["Hello", "World"] 的第 0 个元素："Hello"
# 0[1] 示意取 ["Hello", "World"] 的第 1 个元素："World"
listIndexFormat = "{0[0]}{0[1]}".format(["Hello", "World"])
# 0[0] 示意取 ["0", "1"] 的第 0 个元素："1"
# 1[Hello] 示意取 {"Hello": "World"} 键值为 Hello 的字典元素："World"
dictIndexFormat = "0{0[0]}, 1{0[1]}, Hello{1[Hello]}".format(["0", "1"], {"Hello": "World"})

执行上述代码能够取得如下 YAML 输入:

listIndexFormat: HelloWorld
dictIndexFormat: "00, 11, HelloWorld"

KCL 语言 Playground 更新

在此次更新中，咱们更新了 KCL Playground 的版本并反对 KCL 代码主动编译和格式化两项能力，您能够通过拜访 KCL 官网 并点击 Playground 按钮进行体验。

在后续 KCL 版本中，咱们会继续更新 KCL Playground 更多能力反对如 KCL 版本抉择与代码分享等性能。

KCL 更多平台和更多下载方式反对

Windows 版本反对

KCL Windows 二进制版本能够从 Github 手动下载并装置，下载实现后将 {install-location}\kclvm\bin 增加到环境变量 PATH 中。

$env:PATH += ";{install-location}\kclvm\bin;"

此外，还能够通过如下所示的 Powershell 脚本进行装置:

powershell -Command "iwr -useb https://kcl-lang.io/script/install.ps1 | iex"

咱们后续会反对更多的 Windows 包治理下载方式，如 Scoop 等。

更多下载方式反对

在此次版本更新中，咱们反对了更多的 KCL 下载方式，包含脚本, Python, Go, Homebrew 和 Docker 一键装置，更多具体内容请参考 KCL 下载与装置，后续咱们会反对更多 KCL 装置形式。

⚠️ 留神：对于上述所有操作系统和装置形式，如果要应用 KCL Python 插件 能力，须要确保曾经装置了 Python 3.7+ 版本并将 python3 命令增加到您的 PATH 环境变量中。

谬误修复

当存在非配置表达式的右值时配置合并程序谬误

schema Resource:
    cpu: int
    memory: str

schema Config:
    resource: Resource

r = Resource {
    cpu = 4
    memory = "8Gi"
}

config: Config {
    resource: Resource {
        cpu = 2
        memory = "4Gi"
    }
}

config: Config {resource: r}

在 KCL v0.4.5 版本之前，执行上述代码 (main.k) 会失去非预期的配置值，是因为 KCL 编译器谬误地优化了如下模式等效合并配置块

config: Config {
    resource: r
    resource: Resource {
        cpu = 2
        memory = "4Gi"
    }
}

KCL v0.4.5 版本更新后，修改了不正确配置合并程序，能够执行 main.k 并取得预期的 YAML 输入:

r:
  cpu: 4
  memory: 8Gi
config:
  resource:
    cpu: 4
    memory: 8Gi

更多详情请参考 KCL Issue #422

配置 if 表达式类型不匹配谬误优化

config: {"A"|"B": int} = {
    if True:
        A = "2"
}

在 KCL v0.4.5 版本之前，对于配置 if 表达式，执行上述代码会失去预期的配置值导致 Type Unsoundness 问题，是因为 KCL 编译器谬误地没有查看出 A 属性的值 "2" 与申明的类型 int 不匹配，KCL v0.4.5 版本更新后，修改了此类问题，能够执行上述代码能够取得预期的类型不匹配谬误:

KCL Compile Error[E2G22] : The type got is inconsistent with the type expected
---> File main.k:1:1
1 |config: {"A"|"B": int} = {1 ^  -> got {str(A):str(2)}
expect {str(A)|str(B):int}, got {str(A):str(2)}

更多详情请参考 KCL Issue #389

Rule 语句校验不失效问题

在之前的 KCL 版本中，在应用如下 rule 规定代码时 (main.k)，ServiceCheckRule 的束缚代码会不失效。

protocol KubeResourceProtocol:
    svc: Service

schema Service:
    name: str

rule ServiceCheckRule for KubeResourceProtocol:
    svc.name != "name"

svc = Service {name = "name"}

ServiceCheckRule {svc = svc}

进行改良后，咱们执行上述代码，会失去一个精确的校验不通过谬误:

KCL Runtime Error[E3B17] : Schema check is failed to check condition
---> File main.k:14
14 |ServiceCheckRule { -> Instance check failed
    ---> File main.k:8
    8 |    svc.name != "name" -> Check failed on the condition
Check failed on check conditions

配置块属性类型推导优化

schema Id:
    id?: int = 1

schema Config:
    data?: {"A"|"B": Id}

c = Config {
    data = {A = Id()  # v0.4.5 版本之前，此处会失去一个类型不匹配谬误
        B = Id()}
}

在 KCL v0.4.5 版本之前，执行上述代码会失去一个非预期的类型不匹配，是因为 KCL 编译器谬误地将 c.data.A 属性的类型推导为 str 类型，导致与 "A"|"B" 字面值联结类型不匹配谬误，KCL v0.4.5 版本更新后，修改了此类问题，能够执行上述代码能够取得预期的 YAML 输入:

c:
  data:
    A:
      id: 1
    B:
      id: 1

赋值语句应用 schema 类型注解谬误优化

schema Foo:
    foo: int

schema Bar:
    bar: int

foo: Foo = Bar {  # v0.4.5 版本之前，此处会失去一个运行时类型不匹配谬误
    bar: 1
}

在 KCL v0.4.5 版本之前，执行上述代码会失去一个运行时类型不匹配谬误，版本更新后，会将此类类型不匹配谬误优化到编译时，将谬误左移，更早地发现此类谬误。

KCL 模块类型应用 ?. 运算符类型谬误修复

import math

data = math?.log(10)  # v0.4.5 版本之前，此处会失去一个非预期的 `math is not defined` 谬误

在 KCL v0.4.5 版本之前，执行上述代码会失去一个非预期的变量未定义谬误，是因为 KCL 编译器没有正确地解决 math module 类型和 ?. 运算符联合应用的状况，版本更新后，此类问题失去修复。

其余更新与谬误修复

更多更新与谬误修复 详见

文档更新

KCL 网站 新增 KCL v0.4.5 文档内容并反对版本化语义选项，目前反对 v0.4.3, v0.4.4 和 v0.4.5 版本抉择。

社区动静

• KCL 社区新增两名内部贡献者 @thinkrapido, @Rishav1707, 感激他们激情并踊跃地参加奉献。
• 感激 @Rishav1707 基于 KCL 建设了 Rust 语言版本的 kcl-loader-rs 子项目，以后版本反对依据 KCL 文件中的 Schema 和配置定义主动生成 Rust 构造体并反对 KCL 值到 Rust 构造体值的反序列化函数。

下一步打算

预计 2023 年 4 月中旬，咱们将公布 KCL v0.4.6 版本，预期重点演进包含：

• KCL 语言进一步编写便利性改良，用户界面继续优化与体验晋升，用户反对和痛点解决
• 全新版本的 KCL Language Server 和 VSCode 语言插件，性能预计 晋升 20 倍，并预期反对代码正告和谬误波浪线提醒，跳转，援用查找等外围根底能力
• 针对 Kubernetes Manifests 配置管理场景痛点继续进行语言能力晋升：如设计提供 Helm KCL Schema 插件以及为 kpt 工具提供 KCL SDK 等
• KCL 包管理工具 KPM 公布，预期反对 Git 仓库代码依赖配置与更新，代码下载等根底能力
• KCL Playground 反对代码分享能力和 KCL 版本抉择能力
• KCL Go SDK 更多能力反对：如反对 KCL Schema 和 Go 构造体的双向转换等
• KCL Python SDK 更多能力反对

更多详情请参考 KCL v0.4.6 Milestone

常见问题及解答

详见 KCL 常见问题

其余资源

感激所有 KCL 用户在此次版本更新过程中提出的贵重的反馈与倡议。更多其余资源请参考：

• KCL 网站
• Kusion 网站
• KCL Github 仓库
• Kusion Github 仓库
• Konfig Github 仓库

欢送退出咱们的社区进行交换 👏👏👏：https://github.com/KusionStack/community