Open repi opened 1 year ago
I'm not sure how easy it would be to implement in practice, because this surfaces as an error, whereas cargo vet prune
expects to be run in a passing state.
We could of course just make the tool automatically remove the irrelevant entries, but we went with an explicit error so that (1) it would be less mysterious why a policy entry was disappearing, and (2) users would be less likely to inadvertently drop an important policy when a crate was renamed or something.
The audit-as
checking is actually handled independently from the rest of the resolver, so I don't think it would technically interfere with cargo vet prune
. We'd effectively need to make cargo vet prune
start by running a pared-down version of cargo vet regenerate audit-as-crates-io
which is only allowed to fix a subset of the issues before carrying on as-before (e.g. we wouldn't want it to add new audit-as entries like the regenerate command does IIRC).
On that note, if you weren't aware of that subcommand, I believe you should be able to run it rather than removing the entries manually as well.
does cargo vet regenerate audit-as-crates-io
remove [policy]
elements for unused crates, regardless if they contained the audit-as-crates-io
field or not?
I'm not sure. @mystor ?
Apparently it does not, though there is a comment in the logic considering that behaviour dating back to #368 though.
At one point I think I had considered pruning completely empty [policy]
entries as part of formatting or similar, though the requirements around versioned policy entries does make that a bit more complex nowadays.
If you have removed a dependency that you had a
[policy.crate-name]
for in yourconfig.toml
you get the following nice and clear warning:though instead of having to remove that manually in your config file, is this something
cargo prune
could do for you to streamline things?