You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe:
Hello! I quickly talked about this on slack a while ago, but thought I should put it in writing here with more details.
I'm a crossplane user, in which we can use function-kcl to implement a composition.
As parameters of that function, we can inline the KCL code we want to run, which is the best for rapid feedback and simply packaging the crossplane definitions/compositions into a configuration, but quickly falls short when the code gets complex: we want to write in a kcl file rather than inside the field of a yaml, import external modules for additional schemas, split into multiple files...
Very quickly, the next step is to write the composition in KCL with a code like this:
But this still doesn't solve the multi-files and external modules problem.
The next step that is recommended is to not use inline code but refer to a published module. That would solve the problems, however it introduces major pains in terms of developer experience: testing locally requires us to build and push the module (if it's to the prod registry it pollutes it with many tags since we can't overwrite an existing one, and if we use a different ephemeral registry for testing, the composition isn't the same while testing and in prod), syncing the dependencies with the dependencies field of KCLInput, and synchronize the version of what we push within the composition.
In our organization it's even worse: since what we are building is the foundation of our infrastructure and the registry itself, we have a chicken and egg problem and can't rely on an existing registry, we need the composition yaml to be self-sufficient.
Describe the feature you'd like:
The ideal situation for me would be to combine the convenience of inline sources for packaging with the developer experience of a full fledged module.
For that, what I'd need is a way to "bundle" or "minify" a kcl codebase from an entrypoint into a single kcl file, in which all references to other files and modules are inlined. That file could be then be referenced like the example posted above. Even better, if that was directly provided as a meta-construct in the stdlib, we could simply call it inside the composition.k!
The text was updated successfully, but these errors were encountered:
Thank you for your previous discussion on Slack. The bundle feature is worth considering. cc @zong-zhe cc @He1pa
In addition, there is another way to complete all abstractions on the client side and directly generate Crossplane managed resources and apply them to the cluster, rather than distributing the written KCL code to function kcl. When you are not so dependent on resources in the cluster for configuration and need to use KCL to complete a large amount of logic writing.
Feature Request
Is your feature request related to a problem? Please describe:
Hello! I quickly talked about this on slack a while ago, but thought I should put it in writing here with more details.
I'm a crossplane user, in which we can use function-kcl to implement a composition.
As parameters of that function, we can inline the KCL code we want to run, which is the best for rapid feedback and simply packaging the crossplane definitions/compositions into a configuration, but quickly falls short when the code gets complex: we want to write in a kcl file rather than inside the field of a yaml, import external modules for additional schemas, split into multiple files...
Very quickly, the next step is to write the composition in KCL with a code like this:
But this still doesn't solve the multi-files and external modules problem.
The next step that is recommended is to not use inline code but refer to a published module. That would solve the problems, however it introduces major pains in terms of developer experience: testing locally requires us to build and push the module (if it's to the prod registry it pollutes it with many tags since we can't overwrite an existing one, and if we use a different ephemeral registry for testing, the composition isn't the same while testing and in prod), syncing the dependencies with the dependencies field of KCLInput, and synchronize the version of what we push within the composition.
In our organization it's even worse: since what we are building is the foundation of our infrastructure and the registry itself, we have a chicken and egg problem and can't rely on an existing registry, we need the composition yaml to be self-sufficient.
Describe the feature you'd like:
The ideal situation for me would be to combine the convenience of inline sources for packaging with the developer experience of a full fledged module.
For that, what I'd need is a way to "bundle" or "minify" a kcl codebase from an entrypoint into a single kcl file, in which all references to other files and modules are inlined. That file could be then be referenced like the example posted above. Even better, if that was directly provided as a meta-construct in the stdlib, we could simply call it inside the composition.k!
The text was updated successfully, but these errors were encountered: