feat: cut over Makefile, tox.ini, and CI to uv (2/5)

[irfanuddinahmad]

Summary

PR 2 of 5 in the pip-compile -> uv migration tracked in openedx/public-engineering#543 (child of #506).

Stacked on #38835 (PR 1) — this branch is based on irfanuddinahmad/uv-migration-01-pyproject-deps, so this diff only shows PR 2's own changes. It'll retarget to master automatically once PR 1 merges.

1. PR 1 (feat: add pyproject.toml deps, dependency-groups, and uv.lock (1/5) #38835) — populate pyproject.toml deps/dependency-groups + commit uv.lock (additive only)
2. PR 2 (this PR) — cut over Makefile, tox.ini, and CI to uv; delete the old requirements/edx/*.{in,txt} files
3. PR 3 — migrate the codejail sandbox (requirements/edx-sandbox/) to its own standalone uv project
4. PR 4 — migrate the three standalone scripts to standalone uv projects
5. PR 5 — cleanup docs/README and follow-through on tracking issues

What changed

• Makefile: dev-requirements/base-requirements/test-requirements now call uv sync with the appropriate group flags (--group dev, --no-default-groups, --only-group testing) instead of pip-sync. Target names are kept stable since several CI workflows call them by name. compile-requirements/upgrade now run edx_lint write_uv_constraints + uv lock, and still pip-compile requirements/edx-sandbox + scripts/* (not migrated until PR 3/4) — see "Intentionally not deleted yet" below.
• tox.ini: tox-uv>=1 + runner = uv-venv-lock-runner + dependency_groups = testing, replacing usedevelop/commands_pre = make test-requirements. Also fixed a pre-existing bug: envlist = py{312} quality (space-separated) is misparsed by current tox as a single env py312quality — needed a comma.
• ~13 CI workflows (unit-tests, quality-checks, js-tests, semgrep, static-assets-check, migrations-check, lint-imports, ci-static-analysis, pylint-checks, compile-python-requirements, check-consistent-dependencies, upgrade-one-python-dependency): add astral-sh/setup-uv, add .venv/bin to $GITHUB_PATH after uv sync so later steps' bare python/pytest resolve correctly, and replace bare pip freeze/pip install/pip check with uv pip freeze/uv pip install/uv pip check (uv-managed venvs don't ship pip).
• .readthedocs.yaml: exports the doc dependency-group to a plain requirements.txt via uv export in a post_create_environment hook, then installs it into RTD's own managed venv via post_install — chosen to avoid restructuring RTD's build model. This one needs real-world verification — I can't test an actual RTD build locally; the first real build after this merges will confirm it.
• requirements/edx/{base,assets,development}.txt: regenerated as uv export --no-emit-project compatibility artifacts (see "Tutor compatibility" below), refreshed automatically by make compile-requirements.
• Docs/scripts: updated README.rst, requirements/README.rst, docs/references/static-assets.rst, docs/concepts/testing/testing.rst, scripts/watch_sass.sh, scripts/compile_sass.py — all had pip install -r requirements/edx/*.txt examples that would otherwise now point at nothing.
• check_python_dependencies.yml disabled (workflow_dispatch only, job if: false): find_python_dependencies (from edx-repo-tools) can only scan flat requirements/*.txt files for undocumented git-hosted deps, not pyproject.toml. Filed openedx/repo-tools#725 to add that support; re-enable once it lands.

⚠️ Breaking changes for local workflows

• This PR is where PR 1's uv.lock versions become the ones actually installed by CI and make. See PR 1's "Dependency version changes" section — most are harmless bumps, but protobuf/wrapt downgrade across a major version (transitively, via edx-django-utils's OpenTelemetry-based FrontendMonitoringMiddleware) and a few packages (django-autocomplete-light, edxval, social-auth-core) jump a major version. Worth a specific look before merging, not just treating this as a mechanical tooling swap.
• make dev-requirements/base-requirements/test-requirements now install into a project-local .venv/ instead of whatever Python is currently active on $PATH. Previously, pip-sync installed into whichever interpreter pip resolved to (an already-activated virtualenv, devstack's system Python, etc.). If you're used to activating your own venv first and then running these targets, packages will now land in .venv/ instead — you'll want source .venv/bin/activate (or uv run ...) afterward. This matches uv's standard project model but is a real change in muscle memory for anyone doing local (non-devstack, non-CI) development.

Intentionally not deleted yet

requirements/constraints.txt, requirements/common_constraints.txt, and requirements/pip-tools.{in,txt} are kept — requirements/edx-sandbox/base.in and all three scripts/*/requirements/*.in files still reference -c ../constraints.txt (or similar) and are still pip-compiled until PR 3/4 migrate them off pip-compile entirely. Deleting these now would break those sub-projects' make compile-requirements.

Tutor compatibility

Confirmed (~/Library/Application Support/tutor/env/build/openedx/Dockerfile) that tutor's Docker build does pip install -r requirements/edx/base.txt -r requirements/edx/assets.txt and separately pip install -r requirements/edx/development.txt, with plain pip, not uv. Deleting these files outright would break every tutor-based Open edX deployment build. Instead, make compile-requirements now regenerates them as uv export --no-hashes --no-emit-project artifacts (verified they exclude the -e . self-reference uv adds by default, which the old files never had and which would likely break tutor's multi-stage build where only the requirements file, not the full source tree, is mounted at that layer).

Bugs found and fixed along the way

1. edx-lint's write_uv_constraints crashes on this repo's pyproject.toml (fixed in PR 1, carries forward here) — confirmed idempotent and safe on the already-populated file, so make upgrade works going forward without repeating the workaround.
2. The org-level openedx/.github reusable upgrade-python-requirements.yml workflow already added uv support (installs uv, calls make upgrade generically) — no changes needed to this repo's upgrade-python-requirements.yml at all. This removes what I'd originally expected to be a blocking external dependency.
3. uv lock/uv sync/uv run (in-project) need libmysqlclient-dev + libxmlsec1-dev system packages that pip-compile apparently didn't need (confirmed empirically: mysqlclient's setup.py unconditionally shells out to pkg-config even for metadata-only PEP 517 hooks, which uv always invokes for sdist-only packages). Added a system-requirements install step to compile-python-requirements.yml, check-consistent-dependencies.yml, and upgrade-one-python-dependency.yml, none of which previously needed it.
4. upgrade-one-python-dependency.yml's constraint patcher moved from sed-patching requirements/constraints.txt to a small tomlkit-based Python snippet editing [tool.edx_lint].uv_constraints in pyproject.toml (run with uv run --no-project to avoid syncing the whole project just to edit a TOML file). Verified end-to-end against a real pyproject.toml copy.

Verification

• make compile-requirements — validated end-to-end in an ubuntu:24.04 container (matching CI's system packages): uv lock succeeds, the tutor-compat exports are generated correctly, and the pip-compile loop for edx-sandbox/scripts/* produces byte-identical output to what's already committed (confirms untouched behavior for the not-yet-migrated sub-projects).
• tox -e quality --notest — validated in the same container; found and fixed the envlist comma bug in the process.
• All touched YAML files validated with yaml.safe_load.
• pyproject.toml/uv.lock from PR 1 unchanged by this PR.

🤖 Generated with Claude Code

[openedx-webhooks]

Thanks for the pull request, @irfanuddinahmad!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.