kube-derive now requires explicit kube-core dependency

[clux]

An unforseen outcome of kube-core is that the proc_macro expects kube-core crate to be available at macro-expansion.

This is fine in this workspace (where we use all the crates), but outside, people now need an explicit dependency on kube-core, that's NOT intended, and am consider yanking this release :/

Tried upgrading `controller-rs``:

   Compiling controller v0.10.0 (/home/clux/repos/controller-rs)
error[E0433]: failed to resolve: use of undeclared crate or module `kube_core`
  --> src/manager.rs:27:10
   |
27 | #[derive(CustomResource, Deserialize, Serialize, Clone, Debug, JsonSchema)]
   |          ^^^^^^^^^^^^^^ use of undeclared crate or module `kube_core`
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: use of undeclared crate or module `kube_core`
  --> src/manager.rs:27:10
   |
27 | #[derive(CustomResource, Deserialize, Serialize, Clone, Debug, JsonSchema)]
   |          ^^^^^^^^^^^^^^ not found in `kube_core::api_resource`

[clux]

Yeah, I missed this point, and don't think we can work around it at the moment. Think we need to make kube a more additive crate, with features:

• core (re-export kube-core)
• client
• service
• config
• derive

And possibly having everything but derive be default. Anyway, I am going to yank this for now.

[kflansburg]

Hmmm, sorry about this, I thought I had made this clear in the original PR.

[kazk]

Yeah, we can probably do the following:

• Enable opting out of most features in kube. We can, but don't need to break it up that much. We can do that later when necessary. Maybe just add client feature that's enabled by default for non-core.
• Reexport kube-core under kube::core, and rewrite #[derive(CustomResource)] to use kube::core
• Then for Eliminate kube-derive Dependency on kube #516, users can do kube = { version = "^0.55.0", default-features = false, features = ["derive"] } to get minimal kube without problematic dependencies.

[kflansburg]

As a short-term fix, I've put together #527 which restores the original import, but provides a flag for depending on kube-core instead.

I imagine that the other proposals will take some time to accomplish, so I figured this short term fix could be useful.

[clux]

As a short-term fix, I've put together #527 which restores the original import, but provides a flag for depending on kube-core instead.

I imagine that the other proposals will take some time to accomplish, so I figured this short term fix could be useful.

I appreciate the solution there. I was close to merging it, but figured we could do it the harder way, which is now merged.

Hmmm, sorry about this, I thought I had made this clear in the original PR.

Yeah, I had just failed to recognise this point, not your fault.
Thanks again for the kube-core split idea, it has made the api module a lot more cleanly delineated.

[clux]

released in 0.55.0