ci(tox): migrate from pip to uv via tox-uv by sentry-junior[bot] · Pull Request #6390 · getsentry/sentry-python

sentry-junior · 2026-05-22T08:42:13Z

Description

add uv and tox-uv to manage python envs and packages instead of pip
use astral-sh/setup-uv action in CI instead of setup-python, top-level uv always uses python3.14
except for 3.6 and 3.7, all python versions now go through tox-uv
3.6 and 3.7 have their own containers which uv picks up through UV_PYTHON_REFERENCE
the SDK is now installed as part of deps and not via package so uv resolves all deps in a single pass, this was necessary since uv resolution is stricter than pip
runtox.sh also uses uv run tox
some other pins were necessary to make CI pass
pre-releases need a special UV_PRERELEASE=ALL for resolution to work, we do not relax this throughout because uv then fetches pre-releases for httpx and such breaking half the matrix

Dev Flow Changes

No need for asdf or pyenv now if you were using it before, just use uv, it will manage both tox and required python versions internally.

New commands:

List tox envs: uv run tox l
Integration tests: uv run tox -e py3.14-{integration}-v{version}
Common tests: uv run tox -e py3.14-common
Run specific test file: TESTPATH=tests/integrations/logging/test_logging.py uv run tox -e py3.14-common
Run single test: TESTPATH=tests/path/to/test_file.py uv run tox -e py3.14-common -- -k "test_name"

TODO

coverage (which is a mess anyway)
dev flow with uv as well - linters, top level tox, test file generation all managed with uv
dev flow for python 3.6/3.7 since uv does not manage those

github-actions · 2026-05-22T08:42:38Z

Codecov Results 📊

✅ 67 passed | Total: 67 | Pass Rate: 100% | Execution Time: 7.57s

All tests are passing successfully.

✅ Patch coverage is 100.00%. Project has 14803 uncovered lines.

Generated by Codecov Action

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

py3.7 celery in CI hangs in test_celery_beat_cron_monitoring::test_explanation. kill_beat slept 1s then opened the pidfile; in the slower py3.7 container startup, the file didn't exist yet, the thread died silently, and beat ran forever (30-min job timeout). Poll for the pidfile up to 30s before starting the kill timer, and dump any future thread exception to stderr so the next failure surfaces a traceback instead of silently hanging. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The pidfile-race fix did not unhang py3.7 celery in CI. pytest-timeout only dumps the parent pytest process's threads — the parent is stuck in pytest-forked's waitpid, so the actual hang is somewhere inside the forked child, invisible. Schedule faulthandler.dump_traceback_later(45) in run_beat (which runs inside the forked child) and cancel it on successful beat shutdown. If beat hangs in CI again, the child's full thread dump lands in the log and tells us where to look. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Previous attempt put faulthandler.dump_traceback_later inside run_beat, but the py3.7 CI hang turns out to happen earlier — start_worker() never returns, so run_beat is never reached and the dump is never armed. Move the diagnostic into an autouse fixture in tests/integrations/celery/integration_tests/conftest.py so it covers the entire test body. Next CI hang should land a thread dump in the log showing where start_worker is wedged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

So the py3.7-container kombu hang reveals its real exception instead of sleeping forever inside retry_over_time. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

After moving py3.6/3.7 jobs into the python:X.Y container, the three beat tests (test_explanation, test_beat_task_crons_success/error) hang in celery's start_worker on py3.7 only — kombu's pre-connect via default_channel never returns. This is a known kombu/redis-py + os.fork interaction on the old pin (kombu 4.6 + redis-py <3.2) that celery 4.4.7 ships with; it worked previously only because the broker was on loopback, not a bridged sibling container. Bumping the existing < (3, 7) skip to < (3, 8). py3.7 is EOL and the same tests run fine on 3.8+. Also dropping the diagnostic faulthandler conftest and the kill_beat exception-printing wrapper now that the root cause is understood; the pidfile-wait fix in kill_beat is kept since it's a legitimate startup-race fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The workflow sets SENTRY_PYTHON_TEST_REDIS_HOST=redis for 3.6/3.7 container runs (since redis is a sibling service container, not on loopback), but tox strips env vars not listed in passenv. The celery beat tests therefore read the default 127.0.0.1, find nothing on loopback inside the python container, and hang in kombu's retry_over_time. Adding the var to passenv fixes it; un-skip the beat tests on py3.7. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

sentry-warden Bot reviewed May 22, 2026

View reviewed changes

Comment thread scripts/populate_tox/tox.jinja Outdated

sentry-junior Bot mentioned this pull request May 26, 2026

Migrate tox from pip backend to uv (tox-uv) #6414

Open

sl0thentr0py force-pushed the chore/migrate-to-tox-uv branch from f7d0dfa to 757ecf4 Compare May 26, 2026 14:24