feat: add pyproject.toml deps, dependency-groups, and uv.lock (1/5)

[irfanuddinahmad]

Summary

Part of the org-wide Python packaging modernization tracked in
openedx/public-engineering#543
(child of #506): migrate
openedx-platform from pip-compile to uv + PEP 621/735 pyproject.toml.

This is PR 1 of 5 in the migration sequence. It is purely additive and
does not change how CI, make, or tox install dependencies today — those
still use requirements/*.in/*.txt + pip-compile as the source of truth
until PR 2 cuts over. The goal of this PR is to introduce the new
pyproject.toml/uv.lock files, get them independently reviewed and
merged, and only then swap the tooling that consumes them.

1. PR 1 (this PR) — populate pyproject.toml deps/dependency-groups + commit uv.lock (additive only)
2. PR 2 — cut over Makefile, tox.ini, and CI workflows 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 (scripts/xblock, scripts/user_retirement, scripts/structures_pruning) to standalone uv projects
5. PR 5 — cleanup docs/README and follow-through on tracking issues for external blockers

What changed

• [project.dependencies]: populated from requirements/edx/kernel.in + bundled.in (previously a placeholder ["setuptools"]). Every entry's explanatory comment (whether originally trailing or on a preceding line) is preserved.
• [project.optional-dependencies].openstack: the legacy requirements/edx/openstack.txt (django-storage-swift) — this is a pluggable runtime storage backend, not a dev-tool dependency group, so it belongs here rather than in [dependency-groups].
• [dependency-groups]: coverage, testing (includes coverage), doc, assets, development (includes testing+doc+assets), semgrep, ci (tox, tox-uv), dev (includes development+ci) — mirrors the current .in file composition (-r chains) using PEP 735 {include-group = "..."}.
• [tool.edx_lint].uv_constraints: the ~20 repo-specific version pins from requirements/constraints.txt, each with its original multi-line rationale/issue-link comment preserved as # lines above the entry.
• [tool.uv].constraint-dependencies: generated by running edx_lint write_uv_constraints pyproject.toml (merges the above with edx-lint's bundled global constraints — confirmed identical to today's requirements/common_constraints.txt, so nothing is lost).
• uv.lock: committed, resolved against Python 3.12 inside an ubuntu:24.04 container (matching CI's actual build environment, since mysqlclient has no prebuilt wheel for any platform and must build from source against libmysqlclient-dev).

Two issues found and fixed during this work

1. edx-lint==6.1.0's write_uv_constraints command crashes (AttributeError: 'OutOfOrderTableProxy' object has no attribute 'add') on any pyproject.toml where [tool] is split across multiple out-of-line sub-tables — which is true here ([tool.setuptools], [tool.pytest.ini_options], [tool.ruff], [tool.importlinter] all already exist) and will be true for essentially every real-world pyproject.toml. Worked around by pre-declaring an empty [tool.uv] table before running the command, but this will also break the ongoing make upgrade workflow added in PR 2 unless fixed upstream. Filing a bug against openedx/edx-lint as a follow-up — flagging here so reviewers are aware this isn't fully resolved yet.
2. The --local <file> flag mentioned in openedx-aspects#359's PR description does not exist in the actually-published edx-lint==6.1.0 — confirmed by installing it and reading the source directly. Used the real, supported mechanism ([tool.edx_lint].uv_constraints) instead.

⚠️ Dependency version changes (not just a tooling swap)

uv.lock is a fresh resolution against the same constraints, not a byte-for-byte carryover of the versions already pinned in the (still-authoritative-until-PR-2) requirements/edx/*.txt files. Diffing the two systematically: of 294 packages shared between the old base.txt and the new uv.lock, 39 resolved to a different version. Most are harmless patch/minor bumps, but a few are worth reviewers' attention specifically:

• protobuf 7.35.1 → 6.33.6 and wrapt 2.2.1 → 1.17.3 — both downgrades across a major version. Root cause: opentelemetry-instrumentation* packages (pulled in transitively via edx-django-utils's FrontendMonitoringMiddleware feature — already pinned >=5.14.1 before this change) require wrapt<2, which cascades to protobuf<7 via grpcio-status/google-api-core. This is a resolver-driven side effect of an already-adopted dependency, not something new I introduced, but it's a real behavior difference from what's currently deployed.
• pycasbin 2.8.0 → 2.2.0 — also a downgrade; I wasn't able to fully trace the constraint forcing this one.
• django-autocomplete-light 4.0.3 → 5.0.0, edxval 4.0.1 → 5.0.1, social-auth-core 4.9.1 → 5.0.2 — major-version upgrades that could carry API/behavior changes worth a changelog check before this becomes the live lockfile in PR 2.

By contrast, the testing/dev dependency-groups are stable: pytest, Django, mypy, edx-lint, and coverage are all unchanged; only ruff/tox saw trivial patch bumps.

This PR itself has no runtime effect (uv.lock isn't wired into anything yet), but PR 2 makes these the versions actually installed by CI and make — recommend reviewing/testing this specific set before that merges, rather than treating this purely as a tooling migration.

External compatibility (tutor/Docker, org-level .github workflows)

Not applicable to this PR — it's purely additive (pyproject.toml + uv.lock only), and doesn't touch Makefile, tox.ini, or any CI workflow. Tutor's Dockerfile and the org-level openedx/.github reusable workflows are addressed starting in PR 2, where the tooling that actually consumes these files changes.

Verification

• python3 -c "import tomllib; tomllib.load(...)" — valid TOML.
• uv lock inside ubuntu:24.04 (matching CI's system packages: libmysqlclient-dev, libxmlsec1-dev) — resolves cleanly to 445 packages.
• Spot-checked every one of the 20 constraint pins against the resolved uv.lock versions (e.g. Django resolves to 5.2.15 not 6.0.x, setuptools to 81.0.0 not 82.x, elasticsearch exactly 7.9.1, etc.) — all honored correctly.
• uv sync --group dev --frozen inside the same container — installs the full ~440-package dev environment cleanly, including openedx-platform itself as an editable install.

🤖 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.