RFC Start Date
N/A -- Already Accepted
Target Plan Accepted Date
N/A -- Already Accepted
Target Transition Unblocked Date
Jul 24, 2026
(PR to unblock transition: openedx/openedx-platform#38915)
Earliest Breaking Changes Unblocked Date
2026-08-05
Rationale
As part of openedx-platform's pip-compile → pyproject.toml + uv migration (public-engineering#543, landed in openedx-platform#38915), pyproject.toml + uv.lock are now the actual source of truth for openedx-platform's Python dependencies.
To avoid breaking external tooling that still does pip install -r requirements/edx/base.txt directly, that PR kept a set of machine-generated compatibility exports (uv export --frozen --no-hashes ... output, regenerated by make compile-requirements) at their old paths. These were meant as a temporary bridge, not a permanent parallel format -- indefinitely hand-generating pip-compatible exports alongside uv.lock defeats part of the point of the migration, and adds ongoing maintenance burden (e.g. the exports have already needed one follow-up fix for a uv-version-dependent formatting difference).
This ticket proposes removing those compatibility exports once known consumers have transitioned to reading from pyproject.toml/uv.lock directly (via uv sync/uv export) instead.
Description
Files to be removed from openedx/openedx-platform (all under version control, all currently regenerated by make compile-requirements):
requirements/edx/base.txt, requirements/edx/assets.txt, requirements/edx/development.txt
requirements/edx-sandbox/base.txt
scripts/xblock/requirements.txt
scripts/user_retirement/requirements/base.txt, scripts/user_retirement/requirements/testing.txt
scripts/structures_pruning/requirements/base.txt, scripts/structures_pruning/requirements/testing.txt
Known consumers that need to transition first (found via a GitHub code search across the openedx org and overhangio/tutor; there may be others not surfaced by that search):
overhangio/tutor -- tutor/templates/build/openedx/Dockerfile does a BuildKit bind-mount of requirements/edx/base.txt and requirements/edx/assets.txt from the edx-platform build stage and pip installs them directly (production image), and separately does pip install -r requirements/edx/development.txt in its development build stage (used for tutor dev images). This is a hard break: every Tutor-based image build (production and dev) fails the moment these files are gone. Needs to switch to installing from pyproject.toml/uv.lock (e.g. uv sync --frozen --no-default-groups or uv export) instead. See overhangio/tutor#1434 for the heads-up filed on their side.
openedx/edx-enterprise -- the weekly Upgrade Requirements GitHub Action (.github/workflows/upgrade-python-requirements.yml, runs every Friday) invokes make upgrade, whose Makefile does curl -fsSL https://raw.githubusercontent.com/openedx/openedx-platform/master/requirements/edx/base.txt (with -f, so a 404 fails the job) to build requirements/edx-platform-constraints.txt -- "treat production package versions from openedx-platform as local constraints for testing." This is a hard break on a ~weekly cadence. Needs to source those constraints from uv.lock instead (e.g. by fetching uv.lock and parsing [[package]] entries, or from a uv export of it).
openedx/openedx-translations -- .github/workflows/extract-translation-source-files.yml conditionally does pip install -r translations/edx-platform/requirements/edx/base.txt guarded by if test -f $EDX_BASE_REQS. This is a soft break -- it degrades gracefully to skipping that install, but should be updated to stop looking for the file.
openedx/repo-tools -- find_dependencies.py's PY_REQS fallback list tries requirements/edx/base.txt first, then requirements/base.txt, then requirements.txt. This is a soft break (manual/occasional-use tool, not CI-gating) -- should be updated to also understand pyproject.toml/uv.lock, similar to the fix proposed for find_python_dependencies in repo-tools#735.
Replacement: pyproject.toml + uv.lock are the source of truth. Anyone needing a flat/frozen requirements-style file can run uv export --frozen --no-hashes --no-default-groups --no-emit-project (or --group <name> for a specific dependency group) themselves against those files, or better, adopt uv sync/uv pip install directly.
Task List
RFC Start Date
N/A -- Already Accepted
Target Plan Accepted Date
N/A -- Already Accepted
Target Transition Unblocked Date
Jul 24, 2026
(PR to unblock transition: openedx/openedx-platform#38915)
Earliest Breaking Changes Unblocked Date
2026-08-05
Rationale
As part of openedx-platform's pip-compile →
pyproject.toml+uvmigration (public-engineering#543, landed in openedx-platform#38915),pyproject.toml+uv.lockare now the actual source of truth for openedx-platform's Python dependencies.To avoid breaking external tooling that still does
pip install -r requirements/edx/base.txtdirectly, that PR kept a set of machine-generated compatibility exports (uv export --frozen --no-hashes ...output, regenerated bymake compile-requirements) at their old paths. These were meant as a temporary bridge, not a permanent parallel format -- indefinitely hand-generating pip-compatible exports alongsideuv.lockdefeats part of the point of the migration, and adds ongoing maintenance burden (e.g. the exports have already needed one follow-up fix for a uv-version-dependent formatting difference).This ticket proposes removing those compatibility exports once known consumers have transitioned to reading from
pyproject.toml/uv.lockdirectly (viauv sync/uv export) instead.Description
Files to be removed from
openedx/openedx-platform(all under version control, all currently regenerated bymake compile-requirements):requirements/edx/base.txt,requirements/edx/assets.txt,requirements/edx/development.txtrequirements/edx-sandbox/base.txtscripts/xblock/requirements.txtscripts/user_retirement/requirements/base.txt,scripts/user_retirement/requirements/testing.txtscripts/structures_pruning/requirements/base.txt,scripts/structures_pruning/requirements/testing.txtKnown consumers that need to transition first (found via a GitHub code search across the
openedxorg andoverhangio/tutor; there may be others not surfaced by that search):overhangio/tutor--tutor/templates/build/openedx/Dockerfiledoes a BuildKit bind-mount ofrequirements/edx/base.txtandrequirements/edx/assets.txtfrom the edx-platform build stage andpip installs them directly (production image), and separately doespip install -r requirements/edx/development.txtin itsdevelopmentbuild stage (used fortutor devimages). This is a hard break: every Tutor-based image build (production and dev) fails the moment these files are gone. Needs to switch to installing frompyproject.toml/uv.lock(e.g.uv sync --frozen --no-default-groupsoruv export) instead. See overhangio/tutor#1434 for the heads-up filed on their side.openedx/edx-enterprise-- the weeklyUpgrade RequirementsGitHub Action (.github/workflows/upgrade-python-requirements.yml, runs every Friday) invokesmake upgrade, whoseMakefiledoescurl -fsSL https://raw.githubusercontent.com/openedx/openedx-platform/master/requirements/edx/base.txt(with-f, so a 404 fails the job) to buildrequirements/edx-platform-constraints.txt-- "treat production package versions from openedx-platform as local constraints for testing." This is a hard break on a ~weekly cadence. Needs to source those constraints fromuv.lockinstead (e.g. by fetchinguv.lockand parsing[[package]]entries, or from auv exportof it).openedx/openedx-translations--.github/workflows/extract-translation-source-files.ymlconditionally doespip install -r translations/edx-platform/requirements/edx/base.txtguarded byif test -f $EDX_BASE_REQS. This is a soft break -- it degrades gracefully to skipping that install, but should be updated to stop looking for the file.openedx/repo-tools--find_dependencies.py'sPY_REQSfallback list triesrequirements/edx/base.txtfirst, thenrequirements/base.txt, thenrequirements.txt. This is a soft break (manual/occasional-use tool, not CI-gating) -- should be updated to also understandpyproject.toml/uv.lock, similar to the fix proposed forfind_python_dependenciesin repo-tools#735.Replacement:
pyproject.toml+uv.lockare the source of truth. Anyone needing a flat/frozen requirements-style file can runuv export --frozen --no-hashes --no-default-groups --no-emit-project(or--group <name>for a specific dependency group) themselves against those files, or better, adoptuv sync/uv pip installdirectly.Task List
overhangio/tutor's Dockerfile to install frompyproject.toml/uv.lockinstead ofrequirements/edx/{base,assets}.txtopenedx/edx-enterprise'sMakefile/upgrade-python-requirements.ymlto source constraints fromuv.lockinstead ofrequirements/edx/base.txtopenedx/openedx-translations's extraction workflow to stop referencingrequirements/edx/base.txtfind_dependencies.py'sPY_REQSfallback similarly#risky-changesonce its status is updated to "Transition Unblocked"openedx-platformonce the above are done and the Breaking Changes Unblocked Date has passed