Evaluate extras and groups when determining auditable packages#18511
Evaluate extras and groups when determining auditable packages#18511
Conversation
|
Can you say a but more of what (sub)set of packages users want to audit? E.g., do we want to evaluate all packages by default, or only the set of default extras and the |
Oh yeah, I under-thought this -- I think by default |
b0e6ad5 to
ffb67a9
Compare
|
Actually even that doesn't make a ton of sense -- I can't think of any user scenario/persona where they'd want to only audit a specific group/extra, rather than just the entire thing. I'm kind of inclined to just drop the extra/group flags entirely, at least for the MVP... (For context, pip-audit doesn't try to do any of this.) |
ffb67a9 to
580cba8
Compare
|
I do think it's reasonable to say |
|
I think auditing everything by default and allowing subset selection broadly makes sense to me. |
|
SG, working on that now. |
|
OK, good for another look! I've updated the main PR description to clarify what I've changed here. |
72d9820 to
7d21220
Compare
| pub all_extras: bool, | ||
|
|
||
| /// Exclude the specified optional dependencies, if `--all-extras` is supplied. | ||
| /// Don't audit the specified optional dependencies. |
There was a problem hiding this comment.
Can comment there, but can you also extend the top level description of the command to talk about extras and dep groups?
There was a problem hiding this comment.
dfe8033 LMK if this is what you're thinking 🙂
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Co-authored-by: konsti <konstin@mailbox.org>
Signed-off-by: William Woodruff <william@astral.sh>
dfe8033 to
19e8ae6
Compare
Summary
I've made
uv audit's approach to handling extras and groups (explicitly) subtractive: we don't support flags like--dev(sinceuv auditaudits everything by default); instead, we only support flags like--no-dev,--no-group, etc., that remove items from the to-be-audited set.To accomplish that, I've abstracted the filtering into a new
Lock::packages_for_auditAPI (maybe there's a better location for it?). Implementation wise, it does a BFS similar to the one used inuv tree. I think there's some room/opportunity for DRYing there but I wanted to keep the PR small/local 🙂See #18506.
Test Plan
None yet.