…irst failure (#17785)

This may be superseded by #17786 but is also simpler and easier to merge
first.

…15473)

<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:

- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->

## Summary

@zanieb in #14916 found an interesting bug. Global pin is the user
preference across projects, but if the project locally has a local pin,
it should be an authoritative constraint and end up with error. This
avoids blocking new projects that intentionally require a newer Python
version than the user’s global default. We still error on a local
`.python-version` inside the project to preserve explicit, repo-scoped
intent.

* Explicit `--python` → Always wins regardless of constraints
* Local `.python-version` → Project-scoped, errors on conflict
* Global `.python-version` → User preference, ignored if conflicts with
project. Global pins are suggestions that can be overridden by project
requirements
* Project `requires-python` → Fallback when no pins exist

Implementation :
* If a global `~/.config/uv/.python-version` conflicts with a project
`requires-python`, we ignore the pin and use the project requirement
* If a local project `.python-version` conflicts, we error, with
guidance to update the pin
* Explicit `--python` continues to override both

Now, global pins are suggestions that can be overridden by project
requirements, rather than hard constraints that block project setup.

## Test Plan

A new has been added in `sync_python_version()` along with manual
testing :
```
harshps22ugp@lab:~/projects/uv$ target/debug/uv python pin --global 3.10
Pinned `/home/harshps22ugp/.config/uv/.python-version` to `3.10`
harshps22ugp@lab:~/projects/uv$ mkdir -p /tmp/uv-global-pin && cd /tmp/uv-global-pin
harshps22ugp@lab:/tmp/uv-global-pin$ cat > pyproject.toml <<'EOF'
> [project]
> name = "project"
> version = "0.1.0"
> requires-python = ">=3.11"
> dependencies = ["anyio==3.7.0"]
> EOF
harshps22ugp@lab:/tmp/uv-global-pin$ /home/harshps22ugp/projects/uv/target/debug/uv sync
Using CPython 3.13.5
Creating virtual environment at: .venv
Resolved 4 packages in 276ms
Prepared 3 packages in 149ms
░░░░░░░░░░░░░░░░░░░░ [0/3] Installing wheels...                                                                                                               warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
         If the cache and target directories are on different filesystems, hardlinking may not be supported.
         If this is intentional, set `export UV_LINK_MODE=copy` or use `--link-mode=copy` to suppress this warning.
Installed 3 packages in 35ms
 + anyio==3.7.0
 + idna==3.10
 + sniffio==1.3.1
harshps22ugp@lab:/tmp/uv-global-pin$ . .venv/bin/activate
(project) harshps22ugp@lab:/tmp/uv-global-pin$ python -V
Python 3.13.5
(project) harshps22ugp@lab:/tmp/uv-global-pin$
```
No error was thrown!

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>

Resolves (partially) #17511

This diff enables comma-separated values for `--extra`, allowing `uv
sync --extra foo,bar` as an alternative to `uv sync --extra foo --extra
bar`.

Currently `uv publish` will always deadlock on publish to pyx if the
token is expired. See
#17832 (comment)

```
❯ uv publish ... -v
DEBUG uv 0.9.28 (0e1351e 2026-01-29)
Checking 19743 files against https://api.pyx.dev/v1/upload/internal/...
DEBUG Using request timeout of 900s
DEBUG Using request timeout of 30s
DEBUG Using request timeout of 900s
DEBUG Refreshing token due to token expired (`2026-02-03T19:38:28Z`)
DEBUG Acquired exclusive lock for `pyx refresh`
DEBUG Token on disk still needs refresh due to token expired (`2026-02-03T19:38:28Z`)
DEBUG Refreshing token due to token expired (`2026-02-03T19:38:28Z`)
INFO Waiting to acquire exclusive lock for `pyx refresh` at `/Users/zb/.local/share/pyx/credentials/3859a629b26fda96/tokens.lock`
```

Under the `relocatable-envs-default` preview feature

See #13994

This PR improves the error message when `UV_HTTP_TIMEOUT` (and related
variables like `UV_REQUEST_TIMEOUT`, `HTTP_TIMEOUT`,
`UV_UPLOAD_HTTP_TIMEOUT`) contains an invalid integer.

It adds a context message `"value should be an integer number of
seconds"` to the parsing error.

**Fixes #16940**

**Changes:**
- Updated `parse_integer_environment_variable` in
`crates/uv-settings/src/lib.rs` to accept an optional help string.
- Updated callsites for timeout variables to provide the context.
- Updated the test `create_venv_with_invalid_http_timeout` in
`crates/uv/tests/it/venv.rs` to verify the new message.

**Example Error (Before):**
```
error: Failed to parse environment variable `UV_HTTP_TIMEOUT` with invalid value `foo` : invalid digit found in string
```

**Example Error (After):**
```
error: Failed to parse environment variable `UV_HTTP_TIMEOUT` with invalid value `foo` : invalid digit found in string; value should be an integer number of seconds
```

---------

Co-authored-by: Zanie Blue <contact@zanie.dev>

Automated update for Python releases.

---------

Co-authored-by: jjhelmus <1050278+jjhelmus@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>