Allow configuring what dependencies may appear in public API

[djc]

Describe your use case

There has long been an RFC for "private" dependencies, which would help crates ascertain that they don't depend on a (particular version of) a crate in public API. Unfortunately it seems like doing this is complex enough in Cargo that no one has gotten around to it.

From reading your blog post it seems like this tool would have access to all the relevant data to allow it to warn when a dependency’s type or trait appears in public API.

This is an important part of semver since bumping a public dependency across a semver-incompatible boundary of course means your own semver is affected, too.

Describe the solution you'd like

It would be great if there was a way to configure this tool to allow or deny dependencies from appearing in public API.

Alternatives, if applicable

No response

Additional Context

No response

[epage]

There has long been an RFC for "private" dependencies, which would help crates ascertain that they don't depend on a (particular version of) a crate in public API.

The RFC: https://rust-lang.github.io/rfcs/1977-public-private-dependencies.html

[obi1kenobi]

This is a good idea — thanks for opening this issue. The Trustfall query engine that cargo-semver-checks is built on can definitely pull this off, and I think what you describe would benefit users and should exist.

In my mind, this check is super valuable, but not quite semver: it prevents a semver hazard (deny dependencies from appearing in API) rather than finding and reporting a semver violation. Semver violation lints check some predicate across crate versions, like "struct field used to exist but is now gone." The query here would only need the current version of the crate, and would look for "types from crates not on approved list that leak through the public API."

In the interest of merging cargo-semver-checks into cargo as soon as possible (#61), @epage and I have decided to keep the cargo-semver-checks scope limited to only checking for semver issues. The best way forward for this issue would be through making the query interface available as a library (#67), and then running the custom query this issue describes (tangentially, #38).

When #67 is resolved, would you be interested in working together to build the functionality you described? I'd be more than happy to mentor.

That would help create this capability faster, because there are only so many things I can build at a time all by myself 😅

[epage]

I have decided to keep the cargo-semver-checks scope limited to only checking for semver issues

To add a little nuance, cargo-semver-checks would be for linting API changes which, in theory, can cover more than just semver, but would not be for linting a snapshot of an API.

[djc]

I understand that this doesn't quite fit with the core problem this tool seeks to solve, but I think it's an important part in practice of solving the same problem; additionally, I don't think creating multiple tools that solve slightly different aspects of the same core issue (fearless upgrades) is a net benefit for downstream users, who would likely be better served by an integrated experience.

Also sorry, but I probably won't have time to write code for this in the near future -- I have too many obligations across the projects I maintain already.