Open musicinmybrain opened 3 months ago
The beginning of this could look something like
let data = std::fs::read_to_string(path)?;
let m: cargo_util_schemas::manifest::TomlManifest = toml::from_str(&data)?;
and then perhaps
let package = *m.package.context("Not a package (only a workspace)")?;
let description = package.description.map(|v| v.as_value().cloned()).flatten();
but after that there are decisions and/or slightly more invasive changes to be made. In particular, cargo_toml
claims a package always has a version, but in cargo-util-schemas
the version
field is an Option<…>
, which is inconsistent with the current definition of onefetch_manifest::Manifest
:
If you'd like, feel free to submit a PR 🙂
Summary 💡
As suggested in a Fedora package review, you might consider replacing the
cargo_toml
crate withcargo-util-schemas
(plustoml
). Whilecargo-util-schemas
doesn’t have as much high-level functionality ascargo_toml
, it seems like it should be adequate for whatonefetch-manifest
needs.Motivation 🔦
The advantage of
cargo-util-schemas
is that it is the official implementation of serialization and deserialization schemas used by cargo itself, so if you use it, you can be confident that yourCargo.toml
support remains consistent with cargo‘s.