Generalize/deduplicate shared CRD definitions

[orf]

Hey, me again 😅.

And, as always, thanks for this amazing library. I'm working with the external-secrets.io CRDs, and I've come up against something pretty annoying.

Within the CRDs, there exists two identical enums: ClusterSecretStores and SecretStores.

Aside from the description these are the same enums with the same members, but as they are represented as different types it becomes convoluted to write code to work on, say, a BeyondTrust provider: it's either a ClusterSecretStoreProviderBeyondtrustServer or a ClusterSecretStoreProviderBeyondtrustServer.

Solving this in the general case seems non-trivial. I have yet to dig into it, but perhaps it could be solved at the API schema generation step? I'd be surprised if somewhere down the stack these two enums are represented as the same type, but that information is lost somewhere during processing which results in the types being duplicated.

I'm implementing something for my company with this library and so I can spend some work time tinkering with this, if you think it's at all possible.

So I'd love your thoughts here!

[orf]

Related: kube-rs/kopium#298

[sebhoss]

Hey thanks for reaching out & the very kind words! However I personally think of this project as nothing more than glue code that delegates all the heavy lifting to kopium, so I'll pass along the praise to those maintainers ^^

About shared struct definitions: In the past, I've added two mechanism in this project:

• .args files that allowed me to overwrite the arguments given to kopium for each individual CRD. The original idea behind that was to generate as much code as possible by enabling as many feature flags of kopium as possible for each CRD. However I ended up mostly using to reduce the number of enabled kopium features to fix compilation issues and later removed it entirely as soon as kopium was able to generate all CRDs that had their own .args file in this repository without any problems (using the --smart-derive-elision switch). https://github.com/metio/kube-custom-resources-rs/blob/2024.3.1/crd-catalog/prometheus-operator/prometheus-operator/monitoring.coreos.com/v1/prometheuses.args was such an example which reduced the defaults args from --derive=Default --derive=PartialEq to just --derive=PartialEq.
• .fixup files that allowed me to modify the CRD itself before passing it to kopium. Originally I needed that because the prometheus-operator CRD had duplicate enum values in upper and lower case which resulted in the same Rust code once passed through kopium and therefore caused a compilation issue. Again, I removed this once kopium was able to handle these cases without any additional help. https://github.com/metio/kube-custom-resources-rs/blob/2024.3.1/crd-catalog/prometheus-operator/prometheus-operator/monitoring.coreos.com/v1/podmonitors.fixup is an example of such a script which removed lower case variants of some enums.

I think even without kube-rs/kopium#298 we can do something here: If we bring back .args files we can elide specific structs. Using --elide kopium will still generate code that references structs that we passed to --elide but won't generate the struct itself which would allow us to provide our own implementation (which we could share across multiple CRDs). The missing import statement referencing our own implementation could be added with a .fixup script that runs after kopium generated code. We could just use sed or something similar to place additional imports into the generated files or maybe kopium could get a --add-import ... (or similar) switch.

What do you think?

Sorry for the long wait here, life and all that other stuff got in my recently 🙏