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.

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

strip trailing + from version number of local Python builds #1771

Merged
merged 1 commit into from
Feb 20, 2024

Conversation

BurntSushi
Copy link
Member

(This PR message is mostly copied from the comment in the code.)

For local builds of Python, at time of writing, the version numbers end with
a +. This makes the version non-PEP-440 compatible since a + indicates
the start of a local segment which must be non-empty. Thus, uv chokes on it
and spits out an error when trying to create a venv using a "local" build
of Python. Arguably, the right fix for this is for CPython to use a PEP-440
compatible version number
.

However, as a work-around for now, as suggested by pradyunsg as one
possible direction forward, we strip the +.

This fix does unfortunately mean that one cannot specify a Python version
constraint that specifically selects a local version
. But at the time of
writing, it seems reasonable to block such functionality on this being fixed
upstream (in some way).

Another alternative would be to treat such invalid versions as strings (which
is what PEP-508 suggests), but this leads to undesirable behavior in this
case. For example, let's say you have a Python constraint of >=3.9.1 and
a local build of Python with a version 3.11.1+. Using string comparisons
would mean the constraint wouldn't be satisfied:

>>> "3.9.1" < "3.11.1+"
False

So in the end, we just strip the trailing +, as was done in the days of old
for legacy version numbers.

I tested this fix by manually confirming that

uv venv --python local/python

failed before it and succeeded after it.

Fixes #1357

(This PR message is mostly copied from the comment in the code.)

For local builds of Python, at time of writing, the version numbers end with
a `+`. This makes the version non-PEP-440 compatible since a `+` indicates
the start of a local segment which must be non-empty. Thus, `uv` chokes on it
and [spits out an error][1] when trying to create a venv using a "local" build
of Python. Arguably, the right fix for this is for [CPython to use a PEP-440
compatible version number][2].

However, as a work-around for now, [as suggested by pradyunsg][3] as one
possible direction forward, we strip the `+`.

This fix does unfortunately mean that one [cannot specify a Python version
constraint that specifically selects a local version][4]. But at the time of
writing, it seems reasonable to block such functionality on this being fixed
upstream (in some way).

Another alternative would be to treat such invalid versions as strings (which
is what PEP-508 suggests), but this leads to undesirable behavior in this
case. For example, let's say you have a Python constraint of `>=3.9.1` and
a local build of Python with a version `3.11.1+`. Using string comparisons
would mean the constraint wouldn't be satisfied:

    >>> "3.9.1" < "3.11.1+"
    False

So in the end, we just strip the trailing `+`, as was done in the days of old
for [legacy version numbers][5].

I tested this fix by manually confirming that

    uv venv --python local/python

failed before it and succeeded after it.

Fixes #1357

[1]: #1357
[2]: python/cpython#99968
[3]: pypa/packaging#678 (comment)
[4]: #1357 (comment)
[5]: https://github.com/pypa/packaging/blob/085ff41692b687ae5b0772a55615b69a5b677be9/packaging/version.py#L168-L193
@BurntSushi BurntSushi merged commit 8480842 into main Feb 20, 2024
7 checks passed
@BurntSushi BurntSushi deleted the ag/fix-1357 branch February 20, 2024 17:57
@BurntSushi BurntSushi added the bug Something isn't working label Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Python versions with trailing +
2 participants