PackageSource::Inherited now has four producers with materially different meanings, and consumers can no longer tell them apart.
| Producer |
What it means |
cargo_toml.rs |
workspace = true, resolved against [workspace.dependencies] |
gradle_catalog.rs |
a version.ref alias shared by several libraries |
pom_xml.rs |
a version this parser could not resolve (a <parent>, a built-in, an undefined property) |
swift_package_resolved.rs |
the version came from a lockfile; there is no manifest declaration anywhere |
The variant was chosen each time for a good mechanical reason — it is the one source giving is_checkable() == true with has_position() == false, which is exactly the "check it, never rewrite it" behaviour all four need. The doc comment on item.rs describes only the first three.
The consumer-visible problem
list --format json emits "source": "inherited". A consumer filtering inherited == true to find entries whose central declaration needs bumping is doing something sensible for Cargo and Gradle, meaningless for Swift (there is no central declaration), and misleading for an unresolvable POM entry (nothing was inherited; something was unreadable).
The empty constraint is currently the only thing distinguishing "declared elsewhere in a file we read" from "we could not read this at all", and that is a second field a consumer has to know to check.
Direction
Add a distinct PackageSource — Locked is the obvious name — meaning the version came from a lockfile rather than any manifest, preserving is_checkable() && !has_position(). That splits Swift out cleanly.
Whether the unresolvable-POM case also deserves its own source is a separate question; DependencyStatus::Undetermined already carries that fact at the result level, so it may not need one at the item level.
Note
This is a data-model change every ecosystem touches, so it wants doing deliberately rather than inside a feature PR. Found while reviewing the Swift reader (#85); the drift started with the Gradle catalog parser (#82).
PackageSource::Inheritednow has four producers with materially different meanings, and consumers can no longer tell them apart.cargo_toml.rsworkspace = true, resolved against[workspace.dependencies]gradle_catalog.rsversion.refalias shared by several librariespom_xml.rs<parent>, a built-in, an undefined property)swift_package_resolved.rsThe variant was chosen each time for a good mechanical reason — it is the one source giving
is_checkable() == truewithhas_position() == false, which is exactly the "check it, never rewrite it" behaviour all four need. The doc comment onitem.rsdescribes only the first three.The consumer-visible problem
list --format jsonemits"source": "inherited". A consumer filteringinherited == trueto find entries whose central declaration needs bumping is doing something sensible for Cargo and Gradle, meaningless for Swift (there is no central declaration), and misleading for an unresolvable POM entry (nothing was inherited; something was unreadable).The empty
constraintis currently the only thing distinguishing "declared elsewhere in a file we read" from "we could not read this at all", and that is a second field a consumer has to know to check.Direction
Add a distinct
PackageSource—Lockedis the obvious name — meaning the version came from a lockfile rather than any manifest, preservingis_checkable() && !has_position(). That splits Swift out cleanly.Whether the unresolvable-POM case also deserves its own source is a separate question;
DependencyStatus::Undeterminedalready carries that fact at the result level, so it may not need one at the item level.Note
This is a data-model change every ecosystem touches, so it wants doing deliberately rather than inside a feature PR. Found while reviewing the Swift reader (#85); the drift started with the Gradle catalog parser (#82).