Skip to content
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

Command to bundle/minify a module into a single file #1839

Open
Chewie opened this issue Jan 23, 2025 · 1 comment
Open

Command to bundle/minify a module into a single file #1839

Chewie opened this issue Jan 23, 2025 · 1 comment

Comments

@Chewie
Copy link

Chewie commented Jan 23, 2025

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:

# Other fields removed for brevity
            pipeline = [
                {
                    functionRef = {
                        name = "crossplane-contrib-function-kcl"
                    }
                    step = _kind.lower()
                    input = {
                        apiVersion = "krm.kcl.dev/v1alpha1"
                        kind = "KCLInput"
                        spec = {
                            source = file.read("<my_inline_file>.k")
                        }
                    }
                }

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!

@Peefy
Copy link
Contributor

Peefy commented Jan 24, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants