Consider using cargo-util-schemas instead of cargo_toml

[musicinmybrain]

Summary 💡

As suggested in a Fedora package review, you might consider replacing the cargo_toml crate with cargo-util-schemas (plus toml). While cargo-util-schemas doesn’t have as much high-level functionality as cargo_toml, it seems like it should be adequate for what onefetch-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 your Cargo.toml support remains consistent with cargo‘s.

[musicinmybrain]

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:

onefetch/manifest/src/lib.rs

Lines 6 to 14 in ac7e2b8

	#[derive(Clone, PartialEq, Eq, Debug)]
	pub struct Manifest {
	pub manifest_type: ManifestType,
	pub number_of_dependencies: usize,
	pub name: String,
	pub description: Option<String>,
	pub version: String,
	pub license: Option<String>,
	}

[spenserblack]

If you'd like, feel free to submit a PR 🙂