Migration to schemars 1.0

[joelsa]

Schemars 1.0 has been out for about two months now and adds some interesting features, like support for garde as an alternative to validator.

Per #1336, migration wasn't desired at the time, but I'm wondering if that's still the case now that schemars has continued to mature.

I took a quick look and think the migration might be doable in roughly a day's work, though I haven't dug into all the details yet. One important aspect is that 1.0 does make heavy use of Cow<'static, str> though.

Is there interest in migrating to 1.0 in the near-future at all? Happy to investigate further and work on it if so.

[davepacheco]

CC @ahl

[ahl]

We use dropshot in many distinct--but interrelated--repos here at Oxide. I believe that migrating to schemars 1.0 would necessitate a coordinated update across all our repos--but it's possible that there are some clever ways that dropshot might be able to support schemars 0.8 and 1.0 simultaneously. In the past when we've needed to do a multi-repo coordinated change (e.g. for uuid 1.0) it was a significant pain in the neck.

While the interface presented in 1.0 is cleaner (i.e. JsonSchema::json_schema(..) -> serde_json::Value), there's no real benefit to us (Oxide)--and it will be a fair bit of work to update our various custom JsonSchema implementations (though, perhaps an good task for an LLM).

---

After some prototyping, I'm now pretty sure we could support schemars 0.8 and 1.0 simultaneously--and that might be a viable path. So the short answer is "no there's not much interest in migrating to 1.0 in the near future at all"; the longer answer is that I'll explore a path and share my results in a week or two irrespective of how far I've gotten.

[copumpkin]

Adding some interest here. 0.8 has annoying behavior and loses enum variant names if they have documentation, which means downstream openapi consumers need to treat the variant constructors as anonymous. As far as I can tell, 1.0 (and 1.2 is now released too) does this more nicely, or at least gives me some additional control over it.

[ahl]

0.8 has annoying behavior and loses enum variant names if they have documentation, which means downstream openapi consumers need to treat the variant constructors as anonymous.

Interesting; do you have a repro for this?

[adamchalmers]

Just noting that schemars 1.0 adds some nice new kinds of expressivity. For example, it can handle #[serde(untagged)] on an enum variant, which lets you take a field that was previously, say, i32, and generalize it to an enum like

#[serde(tag = "type")
MyEnum {
  String(String),
  #[serde(untagged)
  Number(i32),
}

Anyway. Just another vote for supporting schemars 1.0 for that reason.