Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip bin-only targets in --workspace runs #163

Open
obi1kenobi opened this issue Oct 30, 2022 · 5 comments
Open

Skip bin-only targets in --workspace runs #163

obi1kenobi opened this issue Oct 30, 2022 · 5 comments
Assignees
Labels
A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations

Comments

@obi1kenobi
Copy link
Owner

obi1kenobi commented Oct 30, 2022

What should cargo-semver-checks' behavior be when asked to semver-check a crate that only has a bin target?
(a) It could exit 1 and report an error.
(b) It could exit 0 without running any semver checks, and report that this was the case since there was no lib target in the crate.
(c) It could run semver checks as if the bin target was a library.

Things to keep in mind:

  • The --workspace flag can implicitly ask cargo-semver-checks to check a bin-only crate, since it asks it to check all crates in the workspace. This makes option (a) unappealing unless we also include logic to skip bin-only crates when --workspace is applied.
  • Crates can have more than one target: both multiple bin targets, as well as a lib target together with one or more bin targets are possible. If a lib target is present, it should obviously be checked. If choosing option (c), should all the bin targets also be checked?
  • Cargo.toml isn't required to have a [lib] or [[bin]] section: if the crate has a main.rs it's assumed to have a [[bin]] with the same name as the crate, and if it has a lib.rs it's assumed to have a [lib] with the same name. This makes it somewhat inconvenient to detect whether a crate with a default target is a lib crate or not, and we'd either need to be extra careful in the implementation or accept that implicit-bin crates might get checked as if they were lib crates.

I'm inclined toward option (b).

Option (c) would require that we check all bin targets present in addition to any lib target, which doesn't seem useful and may be confusing -- and may require adding additional logic if users want to exclude certain bin targets from checking.

And option (a) seems like it would be both more work and also like it might lead to some inconsistency: rustdoc JSON files don't inherently include info on whether they were generated for a lib or bin target, and it's possible to manually generate rustdoc JSON for bin targets and have cargo-semver-checks scan them.

@obi1kenobi obi1kenobi added A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations labels Oct 30, 2022
@obi1kenobi
Copy link
Owner Author

Related to #162 since the JSON file's name by default is the name of the target, not the name of the crate. By default, lib targets share the name of the crate.

@obi1kenobi
Copy link
Owner Author

Also related to #86.

@epage
Copy link
Collaborator

epage commented Oct 31, 2022

Checking the API is meaningless and on its own, I think it'd deserve an error. We could have --workspace automatically skip [[bin]] only crates. That should be easy with cargo_metadata as it reports back package information with all of the implicit fields populated for us.

What would change my answer is when we start checking feature flags. I think I still lean towards erroring for [[bin]]]s as the focus is on APIs for crates and not crates generally.

@obi1kenobi
Copy link
Owner Author

obi1kenobi commented Jan 8, 2023

Let's make checking bin-only crates an error, and make --workspace skip them automatically. If --workspace ends up skipping everything, that should be an error too.

Overall, asking for a semver-check that finds nothing that can be checked is an "mismatch between tool capabilities and user expectations" error, not a silent success.

@obi1kenobi obi1kenobi changed the title Expected behavior when running on bin targets Make running on bin-only targets an error, and skip bin-only targets in --workspace Jan 8, 2023
@obi1kenobi
Copy link
Owner Author

obi1kenobi commented Feb 13, 2024

As of #663 attempting to check bin-only targets is now an error.

I'm planning to start adding workspace-level tests to pin down cargo-semver-checks' behavior in workspaces.

@obi1kenobi obi1kenobi changed the title Make running on bin-only targets an error, and skip bin-only targets in --workspace Skip bin-only targets in --workspace runs Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations
Projects
None yet
Development

No branches or pull requests

2 participants