OEP-67: Add uv and pyproject.toml as backend standards, archive OEP-18

[feanil]

Summary

• Add two backend technology entries to OEP-67: pyproject.toml (PEP 621/735) for declaring project metadata and dependencies, and uv for dependency locking and virtual environment management.

• Add the first backend ADR (decisions/backend/0001-uv.rst) documenting the decision to adopt uv over pip-tools, Poetry, and PDM. Includes comprehensive examples (pyproject.toml, tox.ini, common commands).

• Archive OEP-18 (Python Dependency Management) as Replaced, following the same pattern used when OEP-11 was superseded by OEP-67.

Why now

The Python packaging ecosystem has standardized on pyproject.toml for project metadata (PEP 621) and dependency groups (PEP 735). uv provides a fast, unified tool that natively supports these standards — consolidating dependency resolution, locking, venv management, and tool execution.

Meanwhile, pip-tools (the current OEP-18 standard) does not support PEP 735 dependency groups, and Jazzband — the organization maintaining pip-tools — is sunsetting, raising questions about long-term maintenance.

Open edX repositories should adopt pyproject.toml + uv as the standard approach for Python dependency management. The existing make upgrade workflow is preserved — the target runs uv lock --upgrade instead of pip-compile --upgrade. OEP-18's pip-tools workflow should be superseded.

Rendered Versions of Changed Pages

• OEP Index
• OEP-67 - Standard Tools and Technologies
• New ADR for using uv
• Archived OEP-18

Proof-of-concept migrations

• feat: add write_uv_constraints command to manage uv constraint-dependencies edx-lint#537 — edx_lint write_uv_constraints command for shared constraints
• feat: replace pip-compile with uv sample-plugin#31 — full migration from pip-tools to uv (the ADR examples are drawn from this)
• feat: replace sync_constraints.py with edx_lint write_uv_constraints openedx-aspects#359 — adopting the new constraint tooling

[robrap]

@feanil: Is there any need for a DEPR for the migration? Possibly not. I haven't thought this through. Just asking. Thanks.

[feanil]

I don't think this needs a DEPR. I'm planning on announcing pretty widely before merging this which I think will be sufficient. If others feel strongly that there should be a corresponding DEPR. I'm happy to have them create/manage that DEPR and I can follow its schedule for merging this.

[robrap]

@feanil: You can decide. Fast track DEPR is obviously an option that wouldn't affect your schedule, and it might just widen your inform, for those that listen for DEPRs. Something to consider. Thanks and good luck.

[sarina]

This is great, thanks for putting it together. Added a couple nits to be addressed but I don't need to re-review.

[bradenmacdonald]

💯

[bmtcril]

🚀