make schema a default compile feature of kube-derive - for #355

[clux]

While the issue was closed, and the solution we have seems pretty solid, I can also see a case for people wishing to minimise their dependency trees a bit.

This adds a #[kube(skip_crd)] bool to kube-derive which cases Foo::crd to not be implemented.

Because of how good the crd generation now is, it's opt-out, rather than opt-in.

[clux]

cc @kazk in case you are working on more :-)

[clux]

Note that I feel that it be more ideal if we did this based on whether or not the type already derives JsonSchema, but have not found an easy way to intercept that in a proc-macro.

[kazk]

Looks good to me 👍

This will be nice for those who want to minimize dependency like you wrote. For those that already have schema written manually with validation rules and want to update with minimal change, they should be able to do the following (example from #264 (comment)):

impl JsonSchema for H2OSpec {
    // ...
    fn json_schema(_: &mut SchemaGenerator) -> Schema {
        serde_yaml::from_str(H2O_SPEC_SCHEMA).unwrap()
    }
}

const H2O_SPEC_SCHEMA: &str = r#"
# just the value of openAPIV3Schema
"#;

Note that I feel that it be more ideal if we did this based on whether or not the type already derives JsonSchema, but have not found an easy way to intercept that in a proc-macro.

Yeah, I couldn't find it either when I looked into making v1beta1 opt-in. It's also possible to manually implement JsonSchema and we don't want to skip that.
I also considered adding a feature schemars that's enabled by default.

[clux]

I also considered adding a feature schemars that's enabled by default.

hmmm, that is also a good solution. Possibly even better than this.

The manual hijack of h2o you mentioned is definitely usable, but leaves a little to be desired on our end. A couple of CONs:

• skip_crd wouldn't let h20 partially override it (and attach it to the schema object), as it's removing the method, meaning they would have to hand-write the entire crd
• a schemars feature wouldn't serve as a usual feature which removes a dependency from the library, because the dependency is in the generated code
• even if users manually impl JsonSchema on the root spec struct with a rawstring (like your example), they still need schemars in scope just to do this

The only way to allow manual specification with some safety, and at the same time not have the schemars dependency, would have to be a schemars feature which removes all invocations to the schema generation.
That way users could create a schema object manually as yaml, and try coerce that into a k8s-openapi::..::JSONSchemaProps. We would still generate most of the ::crd(), but it would not be be accepted by the v1 API server, unless users provided the schema manually.

The benefit of all this, I guess, would be that they would have at least serde errors if they wrote the manual schema with typos, or in a format not inline with k8s-openapi.

Whether or not it's worth it, is another question. But it's at least easy to compile-time disable schemars generation, and put in a warning for users that they are in manual mode.

[kazk]

Yeah, I'd vote for schemars feature. It's the most meaningful and the least confusing. I honestly didn't like how we got away with hidden schemars dependency because it's only present in the quoted code. schemars feature will make that clear and provide a way to opt-out 100%.

[clux]

It's now a feature. The hairiest part by far was making the examples + CI able to switch between the various versions of it, but the dedicated example for it should be easy to follow at the very least.