Add a kube::k8s re-export module for stable apis

[clux]

Adds kube_core/src/k8s.rs and makes examples and kube use those imports internally.

• Allows easier imports that bypasses the heavier k8s-openapi directory structure
• Only exposes stable apis from Kubernetes
• Single flat module re-export from kube::core:: showing available stable modules:

Will propagate to kube_client / kube_runtime later if people are happy with this idea and the naming convention (module_name + version no delimiter).

Have been thinking about this before, but was a bit unsure of a) how to do it, and b) if it would make k8s-pb usage harder (it would not - it's kind of necessary for it).

EDIT: sorry, i pinged all of you basically. looking for quick opinions / gut feelings. if you have none, feel free to ignore this.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.3%. Comparing base (ecbdafc) to head (6e1dfb4).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1613   +/-   ##
=====================================
  Coverage   75.3%   75.3%           
=====================================
  Files         82      82           
  Lines       7343    7343           
=====================================
  Hits        5527    5527           
  Misses      1816    1816           

Files with missing lines	Coverage Δ
kube-core/src/crd.rs	83.0% <ø> (ø)
kube-core/src/dynamic.rs	77.1% <ø> (ø)
kube-core/src/gvk.rs	75.5% <ø> (ø)
kube-core/src/labels.rs	90.3% <ø> (ø)
kube-core/src/metadata.rs	67.7% <ø> (ø)
kube-core/src/schema.rs	90.2% <ø> (ø)
kube-core/src/util.rs	100.0% <100.0%> (ø)
kube/src/lib.rs	88.5% <ø> (ø)

[nightkr]

Hm, not quite sure I see the intended use case. You'd still need to take a direct dependency on k8s-openapi to set the k8s compat level feature, right? And we wouldn't really gain much in API stability since breaking k8s-openapi upgrades are still breaking.

The one difference I see remaining, then, is that import paths become shorter to type out manually? (As opposed to letting Rust-Analyzer manage imports.)

[clux]

not quite sure I see the intended use case. [..] import paths become shorter to type out manually?

As it stands, yes. The main benefit is an alternative shorter import path structure. Even with rust analyzer I find myself copy pasting strings because it's not always good enough to navigate 4-5 levels deep, but I usually know the apigroup.

You'd still need to take a direct dependency on k8s-openapi to set the k8s compat level feature, right?

With this PR, yes. But we can avoid the peer-dependency this way if we pin k8s-openapi to latest (which I would like to propose separately to reduce the api surface / variability and simplify our builds).

And we wouldn't really gain much in API stability since breaking k8s-openapi upgrades are still breaking.

Yep. We are releasing a minor right now at every k8s-openapi release, so it's kind of equivalent. This is only intended as an alternative import path. My plan is that this can play into k8s-pb type multiplexing as this type of layer has been very helpful so far in #1602. I liked using it there, so thought to propose it as a thing on its own first.

[Danil-Grigorev]

Personally I think having a re-export of k8s-openapi in kube is useful, as it provides options and allows for extending core k8s types functionality in the crate more straightforward. LGTM

[nightkr]

IMO the k8s-pb saga is another case for reducing the specific coupling to k8s-openapi, but I guess some of that also has to do with how that integration would end up working. I should go look into that...

[Dav1dde]

I think re-exporting only makes sense if there is additional value provided by kube-rs, if it's just re-export to have shorter imports I don't think this is worth it. It may even be confusing if users get k8s-openapi errors without now directly depending on it (e.g. need to select a feature).

If kube-rs now pins k8s-openapi to latest this becomes a bit nicer.