Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

pep508: add requires-python simplification/complexification to MarkerTree #7134

Merged
merged 3 commits into from
Sep 7, 2024
Merged

pep508: add requires-python simplification/complexification to MarkerTree #7134

merged 3 commits into from
Sep 7, 2024

Commits on Sep 6, 2024

  1. pep508: remove hidden state from MarkerTree 

    I split this change into its own commit because I'm hoping it
crystalizes what it means when we say "a `MarkerTree` has hidden state."
That is, it isn't so much that there is some explicit member of a
`MarkerTree` that is omitted, but rather, the lower and upper version
bounds on `python_full_version` are are rewritten as "unbounded" when
traversing the ADD for display.

We will actually retain this functionality, but rejigger it so that it's
explicit when we do this. In particular, this simplification has been
problematic for us because it fundamentally changes the truth tables of
a marker expression *unless* you are extremely careful to interpret it
only under the original context in which it was simplified. This is
quite difficult to do generally, and in prior work in #6268, we
completed a refactor where we worked around this type of simplification
and moved it to the edges of uv.

In subsequent commits, we'll re-implement this form of simplification as
a more explicit step.
    @BurntSushi
    BurntSushi committed Sep 6, 2024
    Configuration menu
    Copy the full SHA
    b414ec0 View commit details
    Browse the repository at this point in the history

  2. pep508: implement marker simplification/complexification 

    This adds new routines to `MarkerTree` for "simplifying" and
"complexifying" a tree with respect to lower and upper Python version
bounds.

In effect, "simplifying" a marker is what you do when you write it to a
lock file. Namely, since `uv.lock` includes a `requires-python` bound at
the top, one can say that it acts as a bound on the supported Python
versions. That is, it establishes a context in which one can assume that
bound is true. Therefore, the markers we write can be simplified using
this assumption.

The reverse is "complexifying" a marker, and it's what you do when you
read a marker from the lock file. Namely, once a marker is read, it can
be very difficult in code to keep the corresponding requires-python
context from the lock file. If you lose track of it and decide to
operate on the "simplified" marker, then it's trivial for that to
produce an incorrect result.
    @BurntSushi
    BurntSushi committed Sep 6, 2024
    Configuration menu
    Copy the full SHA
    2e729fc View commit details
    Browse the repository at this point in the history

  3. uv-resolver: use new simplify/complexify marker routines 

    This finally gets rid of our hack for working around "hidden"
state. We no longer do a roundtrip marker serialization and
deserialization just to avoid the hidden state.
    @BurntSushi
    BurntSushi committed Sep 6, 2024
    Configuration menu
    Copy the full SHA
    f37c755 View commit details
    Browse the repository at this point in the history