1. KPM 是什么

KPM(KCL Package Manager, KCL 包办理器)是 KCL 言语的程序包办理器。

KPM 由两个首要部分组成:

-用于发布和下载程序包的 CLI(指令行界面)东西。

-托管 KCL 程序包的在线存储库。

为了更直观地解说,咱们能够将在线存储库视为一个物流集散中心,该中心从卖方(kpm 包裹的作者)那里接纳货品的包裹,并将这些货品分发给买方(kpm 包裹的用户)。

为了促进此进程,kpm 物流集散中心雇佣了一群勤劳的快递员(kpm CLI),他们将被分配给每个 KCL 用户作为私家助理。因而,KCL 程序所依靠的其他的 KCL 程序包会如下传递给 kcl 开发或许运用人员:

一个关于 KPM 包管理工具诞生的故事

KCL 开发人员也能够将自己开发的 KCL 程序包发布到集散中心:

一个关于 KPM 包管理工具诞生的故事

2. kpm 的诞生

在没有 Kpm 的年代,KCL 的运用者首要就要面对一个很严重的问题。

一个关于 KPM 包管理工具诞生的故事

第一种处理计划,没有自己造呗。

一个关于 KPM 包管理工具诞生的故事

这种计划虽然行得通,但是,投入的本钱太大,周期太长,不现实。

第二种处理计划,搬去物流中心住,里边啥都有。

一个关于 KPM 包管理工具诞生的故事

搬去物流中心能够省去重复造轮子的费事,但是这个计划也存在很明显的问题,在实践的开发进程中,需求凭借类似云端开发的手法,一切人在一个类似 cloud IDE 的环境下开发,开发的时分需求联网,需求保证网络疏通,假如网络不支持的话,就必须要在本地重新搭建一个物流中心,并且将物流中心的全部内容复制到本地才能够正常开发。

一个关于 KPM 包管理工具诞生的故事

每次编译 KCL 包,都要提早准备好整个库房,跟着整个库房规划越来越大,准备库房的本钱也越来越高。

一个关于 KPM 包管理工具诞生的故事

想必参加进程序开发的小伙伴们必定有过这种经历,写过 java 必定用过 maven, 写 python 离不开 pip, 写过 rust 可能没用过 rust 的编译器 rustc,但是 cargo 是必不可少的。这些成熟的言语项目告知咱们,一个成功的言语项目,背面必定有一个包办理东西,担任言语程序包的办理, 静静支撑着编译进程与程序包库房之间的交互。

所以, kpm 诞生了 !

一个关于 KPM 包管理工具诞生的故事

3. 小试牛刀

有了 kpm 后, KCL 就能够经过 import 语句导入各种外部依靠,具体的导入语法如下:

import <external_package_name>.a.b.c   

其中<external_package_name>是被导入的 KCL 程序包的称号,’.a.b.c’ 是导入程序包内部的相对途径。这样,就能够在 KCL 程序中导入各种外部的依靠。

一个关于 KPM 包管理工具诞生的故事

假如没有 kpm 的帮助, KCL 编译器在拿到导入了外部依靠的 KCL 程序后将无法编译, KCL 编译器只担任编译,想要编译一个依靠外部包的 KCL 程序包, 就得首要回答编译器的三个问题。

一个关于 KPM 包管理工具诞生的故事

因而,kpm 引入了 kcl.mod 文件来描绘 KCL 程序包的信息,kcl.mod 中能够描绘当时包的称号,版别以及依靠等编译需求的相关信息。运用 kcl.mod.lock 文件来描绘当时 kcl 程序包依靠项的切当版别。能够运用 kpm init mykcl 指令来初始化一个空的名为 mykcl 程序包。kpm 将会创立一个默认的 kcl.mod 文件如下:

[package]      
name = "mykcl"        
edition = "0.0.1"        
version = "0.0.1"        
       
[dependencies] 

如上所示,[package] 首要担任处理 “你是谁啊” 的问题,

-name : 称号,用来描绘当时 kcl 程序包的称号。

-edition : 编译器的版别字段,用来描绘用来编译当时 KCL 程序包的 KCL 编译器版别。

-version : 当时 KCL 程序包的版别。

[dependencies] 的部分担任处理 “你依靠谁啊” 的问题,首要用来描绘当时 KCL 程序包依靠的外部 KCL 程序包,能够运用 kpm add 指令来为当时 kcl 程序包增加一个外部依靠项,kpm 执行指令 kpm add 进程中,会将下载的 kcl 程序包保存在本地。

以 KCL 程序包 k8s 为例,运用指令 kpm add k8s 下载名为 k8s 的 KCL 程序包,假如要指定版别能够经过 kpm add k8s:1.27.2 这种方式指定版别。

kpm add k8s

下载完成后,能够看到 kpm 已经在 kcl.mod 文件中增加了相关依靠。

[dependencies]      
k8s = "1.27.2"        

并且在 kcl.mod.lock 文件中固定当时依靠项的版别。

[dependencies]      
[dependencies.k8s]        
name = "k8s"        
full_name = "k8s_1.27.2"        
version = "1.27.2"        
sum = "ZI7L/uz53aDOIgVgxBbEPG7wGCWRRLoIY4="  
reg = "ghcr.io"        
repo = "kusionstack.io/k8s"        
oci_tag = "1.27.2"        

经过 kcl.mod 和 kcl.mod.lock 为 KCL 编译器处理了“你是谁”和“依靠谁”的问题,对于”上哪找”的问题,kpm 采取的处理计划是直接将下载包的本地途径传递给 KCL 编译器。

一个关于 KPM 包管理工具诞生的故事

经过 kpm run 指令,运用 kpm 编译 kcl 程序包,kpm 会核算当时 kcl 程序包依靠的外部依靠项,然后调用 kcl 编译器, 并将外部依靠在本地的保存途径传递给 kcl 编译器。

咱们能够在上面创立的 mykcl 包中,增加一个 main.k, 并填入如下内容:

# 从外部的 k8s 包中的导入 apps。       
import k8s.api.apps.v1 as apps        
       
apps.Deployment {        
metadata.name = "nginx-deployment"        
spec = {        
replicas = 3        
selector.matchLabels = {        
app = "nginx"        
}        
template.metadata.labels = {        
app = "nginx"        
}        
template.spec.containers = [        
{        
name = "nginx"        
image = "nginx:1.14.2"        
ports = [        
{containerPort = 80}        
]        
}        
]        
}        
}        

在 mykcl 包中运用指令 kpm run 进行编译。

kpm run

能够得到如下编译成果。

apiVersion: apps/v1      
kind: Deployment        
metadata:        
name: nginx-deployment        
spec:        
replicas: 3        
selector:        
matchLabels:        
app: nginx        
template:        
metadata:        
labels:        
app: nginx        
spec:        
containers:        
- image: "nginx:1.14.2"        
name: nginx        
ports:        
- containerPort: 80        

4. 总结

了解了以上常识,现在你能够开始运用它来办理 KCL 程序包了。咱们将会在后续的文章中进一步介绍运用 kpm 与kpm registry,以及怎么运用它来发布、装置和办理 KCL 程序包。

假如想了解更多关于 KCL 言语和 kpm 的信息,能够访问 KCL 官网获取最新资讯。那么,从速开始运用 kpm 吧 !

  • kcl – github.com/KusionStack…
  • kpm -github.com/KusionStack…
  • kpm 快速开始 -kcl-lang.io/docs/user_d…
  • kcl-kcl-lang.io/