-
-
Notifications
You must be signed in to change notification settings - Fork 307
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
Add a kube::k8s
re-export module for stable apis
#1613
base: main
Are you sure you want to change the base?
Conversation
- Allows easier imports that bypasses the heavier k8s-openapi directory. - Doesn't really expose directly breakable apis (only stable v1/v2 modules) - Easier internal imports - Easier user imports (see later commit) Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
kube::k8s
re-export module for stable apis
Codecov ReportAll modified and coverable lines are covered by tests ✅
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
|
the double exports makes rustdoc not display it properly. this works. adding a png Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
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.) |
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.
With this PR, yes. But we can avoid the peer-dependency this way if we pin k8s-openapi to
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 |
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 |
Adds kube_core/src/k8s.rs and makes examples and kube use those imports internally.
k8s-openapi
directory structurekube::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.