feat: modernize Python tooling to uv + pyproject.toml + semantic-release

[irfanuddinahmad]

Summary

Modernize openedx-core to uv + pyproject.toml (PEP 621/735) + python-semantic-release.

Part of openedx/public-engineering#506 (tracked in openedx/public-engineering#516).

• Replace setup.py/setup.cfg with pyproject.toml (PEP 621 static metadata), version derived from git tags via setuptools-scm
• Switch from pip-compile to uv with PEP 735 dependency groups; commit uv.lock
• Update tox.ini to use tox-uv with uv-venv-lock-runner
• Update CI to use astral-sh/setup-uv; SHA-pin all actions
• Add python-semantic-release + release.yml, replacing the old token-based pypi-publish.yml with OIDC trusted publishing

Not included: src/ layout. This repo already uses src/openedx_{core,content,tagging,catalog} and src/openedx_django_lib, so Phase 0 of the org-wide migration (openedx/public-engineering#506's 2026-07-15 decision) required no changes here — MANIFEST.in, .coveragerc's (now [tool.coverage.run]) source, docs/conf.py's sys.path entries, and tox.ini already pointed at src/.

Removed

Deleted files: setup.py, setup.cfg, .coveragerc, requirements/ (all .in/.txt files, constraints.txt, private.readme), .github/workflows/pypi-publish.yml (replaced by release.yml, OIDC instead of the PYPI_UPLOAD_TOKEN secret).

Removed Makefile targets:

Target	Reason
compile-requirements	pip-compile machinery, replaced by uv lock

upgrade and requirements targets were kept but rewritten to use uv (edx_lint write_uv_constraints + uv lock --upgrade, and uv sync --group dev, respectively) instead of pip-compile/pip-sync.

Versioning

Dynamic — setuptools-scm derives the build version from the latest git tag. Pre-flight check passed: latest git tag v1.1.0 matches the version currently live on PyPI (1.1.0), so the first automated release should compute the correct next version from conventional-commit history.

Testing Notes

Verified locally:

• uv lock resolves cleanly (156 packages)
• uv sync (base project, no groups) succeeds; editable install makes all five packages (openedx_core, openedx_content, openedx_tagging, openedx_django_lib, openedx_catalog) importable, with openedx_core.__version__ correctly resolving to 1.1.0 via importlib.metadata
• python -m build + twine check dist/* both pass; inspected the built wheel and confirmed all five packages (with py.typed markers) are bundled correctly
• mypy resolves the editable install correctly under this repo's existing src/ layout (ran ad hoc with a partial dependency set due to a local sandbox limitation below; it got past all import/plugin resolution and only flagged missing pytest/freezegun stubs from the deliberately-partial ad hoc install, not a resolution problem)
• tox -l lists all envs correctly (py312-django52, quality, docs, pii_check, lint-imports) — tox.ini parses cleanly against the new [dependency-groups] names

Could not verify locally: uv sync --group dev (and test/quality/doc, which all transitively depend on mysqlclient) fails to build in this sandbox because mysqlclient has no macOS wheel on PyPI and needs local MySQL client headers (pkg-config, libmysqlclient) that aren't installable here (no Homebrew/package manager in this sandbox). This is a pre-existing characteristic of the repo (the same coupling existed in the old requirements/quality.txt, which also pulled in mysqlclient transitively via -r test.txt), not something introduced by this migration, and it's expected to build fine on GitHub Actions' ubuntu-latest runners (which ship with MySQL client libraries preinstalled — the same way the pre-migration CI already built mysqlclient without any extra apt-get step). Full test-suite / quality-check execution is therefore relying on this PR's own CI run rather than local verification.

Code reviewer notes

• Two items flagged below need maintainer action, not code changes:
  1. PyPI OIDC trusted publisher needs configuring for openedx-core (tracked in the consolidated comment on Tbain/253 add tags count #506) before the first automated release can publish.
  2. Unable to confirm from outside the org whether the OPENEDX_SEMANTIC_RELEASE_GITHUB_TOKEN secret used by release.yml is configured for this repo.
• Known, out-of-scope gap: .github/workflows/upgrade-python-requirements.yml calls openedx/.github's shared reusable workflow, which hardcodes add-paths: requirements with no override input. Now that requirements/ is deleted, that scheduled job will keep running but silently stop producing real dependency-upgrade PRs (empty diff, no failure, no alert). This can't be fixed from this repo — it needs a fix in openedx/.github itself (e.g. parameterizing add_paths, or auto-detecting uv.lock vs. requirements/).
• mysqlclient is bundled into the test-base dependency group (and therefore test/quality/doc/ci/dev transitively), matching the pre-migration coupling in requirements/test.in → quality.in/doc.in/dev.in. This is why the "Not included"/"Testing Notes" sections above call out the local verification gap.
• [dependency-groups].ci is intentionally minimal (tox, tox-uv only, no include-group) — CI's own uv sync --group ci step only needs tox on PATH; tox installs each env's actual dependency group itself via uv-venv-lock-runner.

---

This PR was created with Claude Code.

[openedx-webhooks]

Thanks for the pull request, @irfanuddinahmad!

This repository is currently maintained by @axim-engineering.

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.

[irfanuddinahmad]

Re-triggering CI: the quality job failed due to a transient Docker Hub registry timeout while pulling mysql:8 (Get "https://registry-1.docker.io/v2/": context deadline exceeded), unrelated to this PR's changes. Closing/reopening to get a fresh CI run since I don't have rerun permissions on this repo.