Conversation
|
Note: marking as ready for review for functionality, but I'm going to add more tests before actually landing this on my feature branch 🙂 |
konstin
left a comment
There was a problem hiding this comment.
Mostly Rust and uv specific comments.
|
I'm not sure how to action these The |
|
The unrelated messages are only warnings, they don't actually error (#18165). For the reqwest feature, can you activate the rustls reqwest-middleware feature as a dev dependency? Otherwise you can use reqwest with no-default-features and the ssl features you need as a dev dependency and put it in the cargo shear ignores. |
|
Okay, I think we're good to go now 🙂 |
b069412 to
96aaeb3
Compare
87cedfc to
6dc0c69
Compare
96aaeb3 to
36af6d9
Compare
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Needed to prevent hyper from only supporting HTTP. Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
d83e170 to
30553d3
Compare
| } | ||
|
|
||
| #[test] | ||
| fn test_deserialize_rangetype() { |
There was a problem hiding this comment.
I don't think we need a separate test for this
There was a problem hiding this comment.
Happy to remove if you feel strongly, but IMO these kinds of serde backstops are nice to have: in this case #[serde(other)] is load-bearing (since it converts unknown variants into Other), and it's nice to have an explicit test in case we ever refactor that.
| "UV_SHOW_RESOLUTION", | ||
| "UV_VENV_CLEAR", | ||
| "UV_VENV_SEED", | ||
| ".." # Include the defaults |
There was a problem hiding this comment.
Nope, this is editor churn. Can remove if you want.
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
Atop #18119. This should be merged into #18119's branch. This adds a `uv-audit` crate, which provides some common types ~~and a trait (`VulnerabilityService`)~~ for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access). Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward. (This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.) I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches. --------- Signed-off-by: William Woodruff <william@astral.sh>
Atop #18119. This should be merged into #18119's branch. This adds a `uv-audit` crate, which provides some common types ~~and a trait (`VulnerabilityService`)~~ for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access). Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward. (This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.) I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches. --------- Signed-off-by: William Woodruff <william@astral.sh>
Atop #18119. This should be merged into #18119's branch. This adds a `uv-audit` crate, which provides some common types ~~and a trait (`VulnerabilityService`)~~ for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access). Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward. (This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.) I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches. --------- Signed-off-by: William Woodruff <william@astral.sh>
Atop #18119. This should be merged into #18119's branch. This adds a `uv-audit` crate, which provides some common types ~~and a trait (`VulnerabilityService`)~~ for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access). Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward. (This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.) I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches. --------- Signed-off-by: William Woodruff <william@astral.sh> Fixup API usage Signed-off-by: William Woodruff <william@astral.sh>
Atop #18119. This should be merged into #18119's branch. This adds a `uv-audit` crate, which provides some common types ~~and a trait (`VulnerabilityService`)~~ for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access). Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward. (This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.) I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches. --------- Signed-off-by: William Woodruff <william@astral.sh> Fixup API usage Signed-off-by: William Woodruff <william@astral.sh>
## Summary This provides the scaffolding (CLI and initial `uv-audit` crate) for a `uv audit` subcommand. Closes #9189. Tracking: - [x] Core CLI scaffolding (this PR) - [x] #18185 - [x] Audit core (probably a new `uv-audit` crate): #18124 - [ ] Bulk dependency audits with OSV - [ ] Result presentation - [ ] #18193 Things that also need to be done with the MVP: - [ ] We should not audit workspace members by default (by definition, they don't exist on indices and therefore don't have meaningful results from vulnerability services). - [ ] I need to ensure groups/etc. are being filtered by correctly, right now we audit every single package in the lockfile unconditionally. ## Test Plan Unit and integration tests commensurate with the new functionality. --------- Signed-off-by: William Woodruff <william@astral.sh>
Atop #18119. This should be merged into #18119's branch. This adds a `uv-audit` crate, which provides some common types ~~and a trait (`VulnerabilityService`)~~ for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access). Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward. (This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.) I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches. --------- Signed-off-by: William Woodruff <william@astral.sh>
Summary
Atop #18119. This should be merged into #18119's branch.
This adds a
uv-auditcrate, which provides some common typesand a trait (for interacting with vulnerability "services" (i.e. online APIs that provide vulnerability DB access).VulnerabilityService)Our MVP service is OSV; supporting PyPI's PYSEC responses through the same trait would be straightforward.
(This should also not increase our dependency footprint; I've only used crates that were already present in our top-level dependencies.)
Test Plan
I've added initial unit tests; I'm going to add more that use a mocked server to ensure we have good coverage of the pagination branches.