Why is patch_status() so "complicated"?

[benkeil]

let status = json!({
    "status": GitHubRepositoryStatus { url }
});
api.patch_status(
    github_repository.metadata.name.as_ref().unwrap(),
    &PatchParams::default(),
    &Patch::Merge(status),
)
.await

Why I can't just do:

api.patch_status(
    github_repository.metadata.name.as_ref().unwrap(),
    &PatchParams::default(),
    &Patch::Merge(GitHubRepositoryStatus { url }),
)
.await

[clux]

Most modifying api calls require taking the whole structure as "required nesting" in the expected data. It feels pretty unnecessary, but it is what the api requires, and it is what we model.

This is usually made somewhat easier with server-side apply and the everything-optional paradigm where you could in theory do something more like GitHubRepository::default().status(gh_status) - if there are some builders available (or you could use a normal struct init using ..Default::default()), which should create the same output as the explicit json! macro when it's serialized, but it's generally a bit awkward with the other patch models.

Then you could in theory do something like:

api.patch_status(
    github_repository.metadata.name.as_ref().unwrap(),
    &PatchParams::default(),
    &Patch::Apply(GitHubRepository { status: GitHubRepositoryStatus { url }, ..Default::default() }),
)
.await

Unfortunately, that thing works for the k8s-openapi types I think; not kube-derive i think, because spec is not optional there so you can't rely on a partial serialization of a struct because the spec is always serialized. So there's the tradeoff between easy subresource patching vs easy option handling everywhere else in the code. Maybe that is worth revisiting 🤔

[clux]

There is also the issue of Patch being generic over T: Serialize prevents us from having a T: Resource bound on any enum variants (due to lack of gadts style specialization which we would need to introduce an optional bound on variants afaikt). It would be great to have ApplyTyped(K: Resource) as a patch option because then you would also be prevented from accidentally putting in a status struct in there (which does not implement Resource).