python sdk kcl_lib 有直接运行示例应用nginx-example的方法吗？我这样配置直接报错！

[Gshelldong]

def exclude_progra_with_mod():
    args = api.ExecProgramArgs(k_filename_list=[
                                                # "D:\myapp\k8s-app-deployer\konfig\examples\\appops\\nginx-example\\base\\base.k",
                                                # "D:\myapp\k8s-app-deployer\konfig\examples\\appops\\nginx-example\\dev\\main.k",
                                                # "D:\myapp\k8s-app-deployer\konfig\models\kube\\render\\render.k"
                                                "konfig\\examples\\appops\\nginx-example\\base\\base.k",
                                                "konfig\\examples\\appops\\nginx-example\\dev\\main.k",
                                                "konfig\\models\kube\\render\\render.k",
                                                ],
                               # k_code_list=['D:\myapp\k8s-app-deployer\konfig\examples\\appops\\nginx-example\\dev\\main.k'],
                               # overrides=["metadata.labels.a=2002"],
                               external_pkgs=[
                                   {"pkg_name": "konfig", "pkg_path": "d:\MyPythonProject\k8s-app-deployer\konfig"},
                                   {"pkg_name": "k8s","pkg_path": "D:\MyPythonProject\k8s-app-deployer\k8s\\1.28"}
                                              ],

                                work_dir="D:\MyPythonProject\k8s-app-deployer"
                               )
    api_client = api.API()
    result = api_client.exec_program(args)
    print(result.err_message)
    return result

---

D:\MyPythonProject\k8s-app-deployer.venv\Scripts\python.exe D:\MyPythonProject\k8s-app-deployer\prase_kcl_tpl.py
Traceback (most recent call last):
File "D:\MyPythonProject\k8s-app-deployer\prase_kcl_tpl.py", line 95, in
print(exclude_progra_with_mod().yaml_result)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\MyPythonProject\k8s-app-deployer\prase_kcl_tpl.py", line 83, in exclude_progra_with_mod
result = api_client.exec_program(args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\MyPythonProject\k8s-app-deployer.venv\Lib\site-packages\kcl_lib\api\service.py", line 140, in exec_program
return self.call("KclService.ExecProgram", args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\MyPythonProject\k8s-app-deployer.venv\Lib\site-packages\kcl_lib\api\service.py", line 667, in call
raise Exception(result.decode(encoding="utf-8").removeprefix("ERROR:"))
Exception:
error[E2L23]: CompileError
--> D:\MyPythonProject\k8s-app-deployer\k8s\1.28\api\networking\v1\ingress_backend.k:6:1
|
6 | import api.core.v1
| ^ the name 'v1' is defined multiple times, 'v1' must be defined only once
|

error[E2G22]: TypeError
--> D:\MyPythonProject\k8s-app-deployer\k8s\1.28\api\networking\v1\ingress_backend.k:22:16
|
22 | resource?: v1.TypedLocalObjectReference
| ^ attribute 'TypedLocalObjectReference' not found in 'module 'k8s.apimachinery.pkg.apis.meta.v1''
|

[Peefy]

Hi! I tried to reproduce your two errors with the same vendored k8s/1.28 layout and pinned the cause to your local k8s/1.28 schema package, not the KCL compiler or kcl_lib. Your ExecProgramArgs shape is correct. Here's what I found:

Root cause

E2L23 — "the name 'v1' is defined multiple times"

Your k8s/1.28/api/networking/v1/ingress_backend.k has two import statements that both alias to v1. The line-6 one (import api.core.v1) is the second; the first (lines 1–5) is import apimachinery.pkg.apis.meta.v1. KCL's import check (sema/resolver/import.rs:139) flags it because the same name resolves to two different module paths.

You can confirm by reading the next error: it says module 'k8s.apimachinery.pkg.apis.meta.v1' — the resolver took the first import, so the second is reported as the conflict.

E2G22 — "'TypedLocalObjectReference' not found in 'k8s.apimachinery.pkg.apis.meta.v1'"

In the canonical KCL Kubernetes schema (the one published under ghcr.io/kcl-lang/k8s), TypedLocalObjectReference lives in api/core/v1/typed_local_object_reference.k, not in apimachinery/pkg/apis/meta/v1/. Your vendored meta/v1 module doesn't export that type, so v1.TypedLocalObjectReference fails to resolve.

For reference, this is what the upstream file looks like (~/.kcl/kpm/k8s_1.32.4/api/networking/v1/ingress_backend.k):

import api.core.v1 as corev1   # aliased to avoid the v1 collision

schema IngressBackend:
    ...
    resource?: corev1.TypedLocalObjectReference

Two key things: it uses as corev1 to dodge the duplicate-v1 collision, and it points at corev1 (not meta/v1) for TypedLocalObjectReference.

Recommended fix — use the official k8s package

The cleanest path is to drop the vendored copy and let kcl mod add k8s resolve it:

cd D:\MyPythonProject\k8s-app-deployer
kcl mod add k8s

Then in Python:

import kcl_lib.api as api

args = api.ExecProgramArgs(
    k_filename_list=[
        r"konfig\examples\appops\nginx-example\base\base.k",
        r"konfig\examples\appops\nginx-example\dev\main.k",
    ],
    work_dir=r"D:\MyPythonProject\k8s-app-deployer",
    # No external_pkgs needed — kcl.mod declares the k8s dependency.
)
result = api.API().exec_program(args)
print(result.err_message or result.yaml_result)

I verified this end-to-end with uv + Python 3.11 + kcl-lib 0.12.4 against the official k8s 1.32.4 package and it runs cleanly.

A few Windows-specific things to watch for in your original snippet:

• Use raw strings r"D:\..." (or double backslashes) for work_dir / pkg_path so \k, \n, etc. don't get mangled.
• ExternalPkg fields are pkg_name / pkg_path — your existing code already has that right.
• k_filename_list paths are resolved relative to work_dir; relative paths are the most portable.

If you need to keep the vendored copy

Two edits:

1. k8s/1.28/api/networking/v1/ingress_backend.k — alias the import and use the qualified name:

   import api.core.v1 as corev1
   
   schema IngressBackend:
       ...
       resource?: corev1.TypedLocalObjectReference
       service?: corev1.ServiceBackendPort

2. Add k8s/1.28/api/core/v1/typed_local_object_reference.k:

   schema TypedLocalObjectReference:
       apiGroup?: str
       kind: str
       name: str

I patched the reproducer locally with those two changes and both E2L23 and E2G22 disappear.

If you want, paste the first ~10 lines of your ingress_backend.k and I can confirm the import line that needs aliasing — happy to dig deeper if your version is more tangled than the one I'm guessing at.

[Peefy]

Quick follow-up after digging deeper into the modules repo:

I went to look at the source and the picture is more nuanced than what I wrote above. Your ingress_backend.k itself was not actually the bug — the published k8s/1.28 already uses import api.core.v1 as corev1 + corev1.TypedLocalObjectReference, the canonical pattern. Your local copy must be from an older regeneration (or a different vendoring).

But the same class of bug exists in 157 other files in k8s/1.28 (and 186 in 1.31), all from this pattern:

import apimachinery.pkg.apis.meta.v1
...
conditions?: [v1.Condition]   # <-- resolves to "apimachinery.pkg.apis.meta.v1" but the
                              #     schema lookup fails because the import path
                              #     isn't aliased

Whenever you import k8s.api.<x>.v1 as <alias>, KCL's relative-import resolver does not fall back into the parent-package namespace, so all the bare v1.<Type> references inside those files turn into attribute 'X' not found in 'module apimachinery.pkg.apis.meta.v1'.

This is the same compiler behavior that blocked konfig's nginx-example (pinned to k8s = "1.31.2"). The kcl k8s schema generator started emitting the as metav1 alias in 1.32+, but 1.14–1.31 were never patched.

I've opened a PR that does the mechanical rewrite for every affected file:

→ kcl-lang/modules#392

What it does:

• 3308 files touched across k8s 1.14 → 1.31
• import apimachinery.pkg.apis.meta.v1 → import apimachinery.pkg.apis.meta.v1 as metav1
• v1.<Type> → metav1.<Type> in the same files

Verified locally against k8s/1.28 and k8s/1.31 via kcl mod + a NetworkPolicy schema that hits metav1.Condition / metav1.LabelSelector. Both compile clean after the patch; both fail before.

If you (or anyone else on Windows) is stuck on a vendored 1.28, you can also just bump to k8s = "1.32.4" in kcl.mod and skip the vendoring entirely. Once the PR lands, the 1.28 vendoring path will work too.

[Peefy]

Just a quick status update: the fix is now merged into the modules repo.

PR: kcl-lang/modules#392 (merged at f36e5838)

What landed:

• k8s 1.14 – 1.31: rewritten so import apimachinery.pkg.apis.meta.v1 becomes import apimachinery.pkg.apis.meta.v1 as metav1, and every in-file v1.<Type> reference becomes metav1.<Type>. ~3.3k files touched.
• CI now exercises every affected version: TestK8sPackages covers k8s 1.14 – 1.33 (20 versions × 4 schemas = 80 cases). The new networkpolicy case specifically instantiates a NetworkPolicy that depends on metav1.ObjectMeta and metav1.LabelSelector, so any future regression on the aliasing will surface as a compile/assertion failure. Latest run on the merged commit is green.

For your case (Windows + vendored 1.28): pull the updated modules and your nginx-example should compile. If you prefer to skip the vendoring entirely, bump k8s = "1.32.4" in your kcl.mod — that path was already clean.

If anything still blows up on your side after re-pulling, drop the new error here and I will dig in.

[Gshelldong]

Thank you!!!

[Gshelldong]

(.venv) D:\MyPythonProject\k8s-app-deployer>pip list | findstr kcl_lib
kcl_lib 0.12.4

import kcl_lib.api as kcl_api

def exclude_progra_with_mod():
    args = kcl_api.ExecProgramArgs(k_filename_list=[
                                                r"konfig\examples\appops\nginx-example\base\base.k",
                                                r"konfig\examples\appops\nginx-example\dev\main.k",
                                                r"konfig\models\kube\render\render.k",
                                                ],
                               external_pkgs=[
                                   {"pkg_name": "konfig", "pkg_path": r"D:\MyPythonProject\k8s-app-deployer\konfig"},
                                   {"pkg_name": "k8s","pkg_path": r"D:\MyPythonProject\k8s-app-deployer\k8s\1.32.4"}
                                              ],

                                work_dir=r"D:\MyPythonProject\k8s-app-deployer"
                               )
    kcl_api_client = kcl_api.API()
    result = kcl_api_client.exec_program(args)
    # print(result)
    return result

if __name__ == '__main__':
    print(exclude_progra_with_mod().err_message or exclude_progra_with_mod().yaml_result)

I pulled the module into the project directory using kcl mod pull k8s:1.32.4 and declared it in external_pkgs. Rendering works fine when I use:

k_filename_list=[
r"konfig\examples\appops\nginx-example\base\base.k",
r"konfig\examples\appops\nginx-example\dev\main.k",
],

However, an error occurs when I add an render.k file as shown below:

k_filename_list=[
r"konfig\examples\appops\nginx-example\base\base.k",
r"konfig\examples\appops\nginx-example\dev\main.k",
r"konfig\models\kube\render\render.k",
]

Error traceback:

D:\MyPythonProject\k8s-app-deployer\.venv\Scripts\python.exe D:\MyPythonProject\k8s-app-deployer\demo.py 
Traceback (most recent call last):
  File "D:\MyPythonProject\k8s-app-deployer\demo.py", line 22, in <module>
    print(exclude_progra_with_mod().err_message or exclude_progra_with_mod().yaml_result)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\MyPythonProject\k8s-app-deployer\demo.py", line 17, in exclude_progra_with_mod
    result = kcl_api_client.exec_program(args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\MyPythonProject\k8s-app-deployer\.venv\Lib\site-packages\kcl_lib\api\service.py", line 140, in exec_program
    return self.call("KclService.ExecProgram", args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\MyPythonProject\k8s-app-deployer\.venv\Lib\site-packages\kcl_lib\api\service.py", line 667, in call
    raise Exception(result.decode(encoding="utf-8").removeprefix("ERROR:"))
Exception: 
error[E2L23]: CompileError
 --> D:\MyPythonProject\k8s-app-deployer\konfig\models\kube\render\render.k:1:1
  |
1 | import models.kube.frontend
  | ^ the name 'frontend' is defined multiple times, 'frontend' must be defined only once
  |


error[E2G22]: TypeError
  --> D:\MyPythonProject\k8s-app-deployer\konfig\models\kube\backend\job_backend.k:40:44
   |
40 |         mainContainer = utils.volume_patch(config.volumes, [utils.ContainerFrontend2Kube(mainContainerDict)])?[0]
   |                                            ^ expected [Volume], got [Volume]
   |

 --> D:\MyPythonProject\k8s-app-deployer\konfig\models\kube\utils\volume_patch.k:5:23
  |
5 | volume_patch = lambda volumes: [volume.Volume], containers: [{str:}] -> [{str:}] {
  |                       ^ variable is defined here, its type is [Volume], but got [Volume]
  |

在konfig\models\kube\render\render.k 这个文件渲染之后的结果才是真正的部署yaml, 那才是我想要的结果，有这个功能吗？

[Gshelldong]

@Peefy help me!!! Thanks!!!

[Peefy]

Quick follow-up on adding render.k to your k_filename_list.

Short answer: yes, that is the intended way to get the actual deployment YAML — render.k calls manifests.yaml_stream(...) which is the built-in pseudo-module that emits multi-document YAML. import manifests works even though there is no manifests package on disk; the KCL compiler treats it as a built-in.

But there are two real bugs in the konfig repo that bite you the moment you try this. I just reproduced both locally with kcl 1.32.4 against the konfig checkout.

---

1. E2L23 the name 'frontend' is defined multiple times at render.k:1

Root cause is in crates/sema/src/resolver/import.rs:139. The check is a raw string comparison on the import path — it does NOT normalize.

• base.k / dev/main.k say import konfig.models.kube.frontend
• render.k says import models.kube.frontend

Both resolve to the same module, but the literal strings differ, so the check raises E2L23. The source comment spells out exactly when this triggers:

// 'import sub as s' and 'import sub.sub as s' will raise this error.
// 'import sub' and 'import sub' will not raise this error.

Two fixes, pick one:

# Option A: align render.k with the example files (full path)
import konfig.models.kube.frontend
import konfig.models.kube.frontend.rbac
import konfig.models.kube.backend
import konfig.models.kube.resource
import k8s.api.core.v1 as corev1
import manifests

# Option B: alias the relative import
import models.kube.frontend as frontend
import models.kube.frontend.rbac

Option A is cleaner and matches every other file in konfig.

---

2. E2G22 expected [Volume], got [Volume] at job_backend.k:40

This is NOT a path problem — it is a real type bug in konfig. Both [Volume] print the same name but they are different schemas:

Position	Type
volume_patch.k:5 lambda's volumes parameter	models.kube.frontend.volume.Volume (konfig's frontend schema)
config.volumes at the call site	also models.kube.frontend.volume.Volume per frontend.Job.volumes declaration

If the types look identical on paper but the compiler still rejects them, the issue is almost always that the same Volume schema is being reached through two different module paths and KCL is comparing by full pkgpath, not by name. When base.k is in the program and pulls in konfig.models.kube.frontend.*, while render.k imports models.kube.frontend.* directly, KCL keeps them as distinct identities.

The error is on the lambda parameter — that parameter is being inferred with whatever pkgpath was used at the lambda definition site (models.kube.frontend.volume.Volume), but config.volumes flows through frontend.Job whose volumes field was bound through the konfig.models.kube.frontend.volume.Volume pkgpath, so the two collide.

The fix is the same as fix #1: make every file agree on the import path. Once render.k uses konfig.models.kube.frontend.* (option A above), the lambda's volume.Volume parameter and config.volumes resolve through the same pkgpath and the E2G22 should disappear.

If after that fix the E2G22 is still there, it's a genuine konfig logic bug and I will dig into volume_patch / to_kube_volume separately.

---

What I am doing about it

I've forked kcl-lang/konfig and will open a PR with the option A fix to render.k. Once it lands, your k_filename_list = [base/base.k, dev/main.k, konfig/models/kube/render/render.k] should drop clean YAML straight to stdout (or into result.yaml_result from the Python SDK).

Will report back here with the PR link once it's open and CI green.

[Gshelldong]

我觉得不应该报这个错误才对，因为中即使是没有传入也应该是默认值。

# D:\MyPythonProject\k8s-app-deployer\konfig\models\kube\frontend\server.k
    # Application replicas
    replicas: int = option("replicas") or 1

[Gshelldong]

换了个kcl_lib的版本可以正常的渲染了！之前使用的是最新的版本kcl_lib 0.12.4
(.venv) D:\MyPythonProject\k8s-app-deployer>pip list | findstr kcl_lib
kcl_lib 0.11.2

[Peefy]

Yes, you are correct. There might be a regression issue here. I will try to fix the konfig code to support different KCL versions, while also fixing bugs within KCL itself.

[Gshelldong]

感谢，幸苦作者。

[Gshelldong]

我发线这个渲染时间比较长有什么思路可以优化下吗？

import time

import kcl_lib.api as kcl_api

def exclude_progra_with_mod():
    args = kcl_api.ExecProgram_Args(
        k_filename_list=[
                        r"examples\appops\nginx-example\base\base.k",
                        r"examples\appops\nginx-example\dev\main.k",
                        r"models\kube\render\render.k",
                        ],
        external_pkgs=[
                       {"pkg_name": "konfig", "pkg_path": r"D:\MyPythonProject\k8s-app-deployer\konfig"},
                       {"pkg_name": "k8s","pkg_path": r"D:\MyPythonProject\k8s-app-deployer\k8s\1.32.4"}
                      ],
        work_dir=r"D:\MyPythonProject\k8s-app-deployer\konfig"
       )
    kcl_api_client = kcl_api.API()
    result = kcl_api_client.exec_program(args)
    # print(result)
    return result

if __name__ == '__main__':
    start = time.time()  # 开始时间
    print(time.ctime())

    res = exclude_progra_with_mod()
    print(res.err_message or res.yaml_result)

    print(time.ctime())
    cost = time.time() - start  # 耗时秒数
    print(f"执行耗时: {cost:.3f} 秒")

---

D:\MyPythonProject\k8s-app-deployer\.venv\Scripts\python.exe D:\MyPythonProject\k8s-app-deployer\demo.py 
Mon Aug 24 17:53:19 2026
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sampleapp-prod
  namespace: sampleappns-prod
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: sampleapp
      app.kubernetes.io/env: prod
      app.kubernetes.io/instance: sampleapp-prod
      app.k8s.io/component: sampleapp-prod
  template:
    metadata:
      labels:
        app.kubernetes.io/name: sampleapp
        app.kubernetes.io/env: prod
        app.kubernetes.io/instance: sampleapp-prod
        app.k8s.io/component: sampleapp-prod
    spec:
      containers:
      - env:
        - name: MY_ENV
          value: MY_VALUE
        image: nginx:1.7.8
        name: main
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          limits:
            cpu: '100m'
            memory: '100Mi'
            ephemeral-storage: '1Gi'
          requests:
            cpu: '100m'
            memory: '100Mi'
            ephemeral-storage: '1Gi'
        volumeMounts: []
---
apiVersion: v1
kind: Namespace
metadata:
  name: sampleappns-prod
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: sampleappns-prod
spec:
  ports:
  - nodePort: 30201
    port: 80
    targetPort: 80
  selector:
    app.kubernetes.io/name: sampleapp
    app.kubernetes.io/env: prod
    app.kubernetes.io/instance: sampleapp-prod
    app.k8s.io/component: sampleapp-prod
  type: NodePort
Mon Aug 24 17:53:23 2026
执行耗时: 4.255 秒