-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove starlark dependencies from api module #3943
Comments
I think this is a great idea. In general I would probably look for limiting the number of "extension points" in kustomize because it can lead to security issues. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
We are instead going to remove Starlark support entirely: #4349 |
As requested in kubernetes/kubernetes#98946, we need to make it possible to use Kustomize as a library without pulling in a starlark dependency. Starlark functionality should remain available in the standalone kustomize binary, but this should be done via injection so that it does not affect kubectl. We can revisit this decision if starlark functions graduate out of alpha, but for now, we don't expose them in kubectl at all.
The text was updated successfully, but these errors were encountered: