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

Clearer variable names #127

Open
negz opened this issue Aug 8, 2024 · 2 comments
Open

Clearer variable names #127

negz opened this issue Aug 8, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@negz
Copy link
Member

negz commented Aug 8, 2024

What problem are you facing?

I'm new to KCL, but I'm pretty familiar with Crossplane functions. I'm taking a look at function-kcl for the first time and finding some of the variable names aren't very intuitive.

How could this Function help solve your problem?

Some early thoughts from my first time working with this function:

  • oxr, ocds, etc are great as optional abbreviations but something like observed.composite.resource makes what the variable is a lot clearer. See for example the Python SDK: https://docs.crossplane.io/v1.16/guides/write-a-composition-function-in-python/#edit-the-template-to-add-the-functions-logic
  • I believe updating items updates the desired resources, right? items is a pretty ambiguous name - could it be something that more clearly indicates that it's updating the desired composed resources?
  • I don't think any other function has the concept of params, which if I follow correctly can contain user supplied params from the function's input, but also has the observed XR etc injected into it. Would it make sense to break the "fixed" inputs like the observed XR out into top-level variables, rather than injecting them into the params?
@negz negz added the enhancement New feature or request label Aug 8, 2024
@Peefy
Copy link
Collaborator

Peefy commented Aug 9, 2024

I agree with your point of view that option("params").oxr can be further simplified. The params field is indeed something that other functions do not have, as it is part of the KRM KCL specification. Of course, we can simplify request input in the function-kcl scenario, such as using option("oxr") or observe.composite.resource or oxr directly without any problems in implementation. The initial consideration for naming the return resource name items is to comply with the specifications of Kustomize/KPT Function, although it can be modified to other names for Crossplane function-kcl

@negz
Copy link
Member Author

negz commented Aug 9, 2024

Got it. Yeah I wondered if some of this was to comply with KCL patterns. If params is idiomatic for KCL then keeping that definitely seems reasonable.

I don't think this function should optimize to match KRM function patterns and terminology though. While I know KRM functions are similar to Crossplane functions, I think it's more user friendly to use terms that'll be familiar to Crossplane users.

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

No branches or pull requests

2 participants