Skip to content
New issue

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

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

Already on GitHub? # to your account

Implement opt-in workspace overrides #812

Merged

Conversation

suaviloquence
Copy link
Contributor

Now workspace overrides only apply when either the lints.workspace = true or package.metadata.cargo-semver-checks.lints.workspace = true key is set, matching the cargo [lints] table behavior. Also adds a test to ensure this behavior stays this way.

Copy link
Owner

@obi1kenobi obi1kenobi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests look great. I trust you to address the workspace = false concern in a subsequent PR.

Comment on lines +528 to +536
let selected_manifest = manifest::Manifest::parse(selected.manifest_path.clone().into_std_path_buf())?;
// the key `lints.workspace` for the Cargo lints table
let lint_workspace_key = selected_manifest.parsed.lints.is_some_and(|x| x.workspace);
let metadata_workspace_key = package_overrides.as_ref().is_some_and(|x| x.workspace);

if lint_workspace_key || metadata_workspace_key {
if let Some(workspace) = &workspace_overrides {
overrides.push(Arc::clone(workspace));
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it's a good idea to explicitly raise an error for workspace = false in either location?

Right now, we silently treat workspace = false as if it were workspace = true, which seems problematic. cargo might enforce an error in the [lints] table, but everything in the metadata table is up to us.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, we silently treat workspace = false as if it were workspace = true

We treat it, at least in the [metadata] table, as the same as if the key was not set. I don't think cargo_toml distinguishes a value of false from None, but we could deserialize the metadata workspace as an Option<bool>, then raise an error if we get Some(false). Does that sound like a good idea?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I was confused by the variable naming -- I thought metadata_workspace_key was testing for the presence of the key, but now I see it's actually holding the value instead.

Your call in that case, I trust your judgment.

@obi1kenobi obi1kenobi merged commit a4f745f into obi1kenobi:main Jul 11, 2024
34 of 35 checks passed
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants