mirrors/uv

mirror of https://github.com/astral-sh/uv.git synced 2025-11-02 04:48:18 +00:00

History

Tom Parker-Shemilt bc963d13cb Annotate sources of requirements (#3269 ) ## Summary Fixes https://github.com/astral-sh/uv/issues/1343. This is kinda a first draft at the moment, but does at least mostly work locally (barring some bits of the test suite that seem to not work for me in general). ## Test Plan Mostly running the existing tests and checking the revised output is sane ## Outstanding issues Most of these come down to "AFAIK, the existing tools don't support these patterns, but `uv` does" and so I'm not sure there's an existing good answer here! Most of the answers so far are "whatever was easiest to build" - [x] ~~Is "-r pyproject.toml" correct? Should it show something else or get skipped entirely~~ No it wasn't. Fixed in `3044fa8b86` - [ ] If the requirements file is stdin, that just gets skipped. Should it be recorded? - [ ] Overrides get shown as "--override<override.txt>". Correct? - [x] ~~Some of the tests (e.g. `dependency_excludes_non_contiguous_range_of_compatible_versions`) make assumptions about the order of package versions being outputted, which this PR breaks. I'm not sure if the text is fairly arbitrary and can be replaced or whether the behaviour needs fixing?~~ - fixed by removing the custom pubgrub PartialEq/Hash - [ ] Are all the `TrackedFromStr` et al changes needed, or is there an easier way? I don't think so, I think it's necessary to track these sort of things fairly comprehensively to make this feature work, and this sort of invasive change feels necessary, but happy to be proved wrong there :) - [x] ~~If you have a requirement coming in from two or more different requirements files only one turns up. I've got a closed-source example for this (can go into more detail if needed), mostly consisting of a complicated set of common deps creating a larger set. It's a rarer case, but worth considering.~~ `042432b200` - [ ] Doesn't add annotations for `setup.py` yet - This is pretty hard, as the correct location to insert the path is `crates/pypi-types/src/metadata.rs`'s `parse_pkg_info`, which as it's based off a source distribution has entirely thrown away such matters as "where did this package requirement get built from". Could add "`built package name`" as a dep, but that's a little odd.		2024-05-08 23:19:22 -04:00
..
src	Annotate sources of requirements (#3269 )	2024-05-08 23:19:22 -04:00
Cargo.lock	Copy over `pep508-rs` crate (#31 )	2023-10-06 20:12:19 -04:00
Cargo.toml	Add basic `tool.uv.sources` support (#3263 )	2024-05-03 21:10:50 +00:00
License-Apache	Copy over `pep508-rs` crate (#31 )	2023-10-06 20:12:19 -04:00
License-BSD	Copy over `pep508-rs` crate (#31 )	2023-10-06 20:12:19 -04:00
Readme.md	Copy over `pep508-rs` crate (#31 )	2023-10-06 20:12:19 -04:00

Readme.md

Dependency specifiers (PEP 508) in Rust

A library for python dependency specifiers, better known as PEP 508.

Usage

In Rust

use std::str::FromStr;
use pep508_rs::Requirement;

let marker = r#"requests [security,tests] >= 2.8.1, == 2.8.* ; python_version > "3.8""#;
let dependency_specification = Requirement::from_str(marker).unwrap();
assert_eq!(dependency_specification.name, "requests");
assert_eq!(dependency_specification.extras, Some(vec!["security".to_string(), "tests".to_string()]));

In Python

from pep508_rs import Requirement

requests = Requirement(
    'requests [security,tests] >= 2.8.1, == 2.8.* ; python_version > "3.8"'
)
assert requests.name == "requests"
assert requests.extras == ["security", "tests"]
assert [str(i) for i in requests.version_or_url] == [">= 2.8.1", "== 2.8.*"]

Python bindings are built with maturin, but you can also use the normal pip install .

Version and VersionSpecifier from pep440_rs are reexported to avoid type mismatches.

Markers

Markers allow you to install dependencies only in specific environments (python version, operating system, architecture, etc.) or when a specific feature is activated. E.g. you can say importlib-metadata ; python_version < "3.8" or itsdangerous (>=1.1.0) ; extra == 'security'. Unfortunately, the marker grammar has some oversights (e.g. https://github.com/pypa/packaging.python.org/pull/1181) and the design of comparisons (PEP 440 comparisons with lexicographic fallback) leads to confusing outcomes. This implementation tries to carefully validate everything and emit warnings whenever bogus comparisons with unintended semantics are made.

In python, warnings are by default sent to the normal python logging infrastructure:

from pep508_rs import Requirement, MarkerEnvironment

env = MarkerEnvironment.current()
assert not Requirement("numpy; extra == 'science'").evaluate_markers(env, [])
assert Requirement("numpy; extra == 'science'").evaluate_markers(env, ["science"])
assert not Requirement(
    "numpy; extra == 'science' and extra == 'arrays'"
).evaluate_markers(env, ["science"])
assert Requirement(
    "numpy; extra == 'science' or extra == 'arrays'"
).evaluate_markers(env, ["science"])

from pep508_rs import Requirement, MarkerEnvironment

env = MarkerEnvironment.current()
Requirement("numpy; python_version >= '3.9.'").evaluate_markers(env, [])
# This will log: 
# "Expected PEP 440 version to compare with python_version, found '3.9.', "
# "evaluating to false: Version `3.9.` doesn't match PEP 440 rules"