From 61dcf2f8d5605ca5de08f5c1270a5f0d242b71b6 Mon Sep 17 00:00:00 2001 From: Irfan Ahmad Date: Wed, 1 Jul 2026 16:59:41 +0500 Subject: [PATCH] chore: remove now-unused pip-compile machinery (uv migration 5/5) Deletes requirements/constraints.txt, common_constraints.txt, and pip-tools.{in,txt} -- these were kept alive through PR 2-4 because requirements/edx-sandbox and scripts/* still pip-compiled against them, but PR 4 was the last consumer, so they're now fully unused. Removes the correspondingly-vestigial Makefile machinery: the pre-requirements target, the COMMON_CONSTRAINTS_TXT curl-fetch-and-sed target, and the CUSTOM_COMPILE_COMMAND/COMPILE_OPTS variables that only existed to feed pip-compile invocations which no longer exist anywhere in this repo. Finalizes requirements/README.rst for the fully-migrated state and fixes a couple of remaining stale references (constraints.txt -> [tool.edx_lint].uv_constraints). This is the last of 5 PRs migrating openedx-platform from pip-compile to uv + PEP 621/735 pyproject.toml, tracked in https://github.com/openedx/public-engineering/issues/543. Two follow-up items remain outside this repo's control: - openedx/repo-tools#725: find_python_dependencies needs pyproject.toml support before check_python_dependencies.yml can be re-enabled. - Tutor's Dockerfile installs from requirements/edx/{base,assets,development}.txt with plain pip; those are kept as `uv export` compatibility artifacts (see PR 2 / #38836) rather than deleted, so no action is required there, but tutor maintainers should be aware these are now generated files. Co-Authored-By: Claude Sonnet 5 --- Makefile | 29 +----- requirements/README.rst | 17 ++-- requirements/common_constraints.txt | 24 ----- requirements/constraints.txt | 152 ---------------------------- requirements/pip-tools.in | 12 --- requirements/pip-tools.txt | 30 ------ 6 files changed, 12 insertions(+), 252 deletions(-) delete mode 100644 requirements/common_constraints.txt delete mode 100644 requirements/constraints.txt delete mode 100644 requirements/pip-tools.in delete mode 100644 requirements/pip-tools.txt diff --git a/Makefile b/Makefile index 4dc38ca50d8d..35069cbda1e4 100644 --- a/Makefile +++ b/Makefile @@ -3,7 +3,7 @@ compile-requirements detect_changed_source_translations dev-requirements \ docs extract_translations \ guides help lint-imports local-requirements migrate migrate-lms migrate-cms \ - pre-requirements pull pull_xblock_translations pull_translations push_translations \ + pull pull_xblock_translations pull_translations push_translations \ requirements shell swagger \ technical-docs test-requirements ubuntu-requirements upgrade-package upgrade @@ -64,9 +64,6 @@ pull_translations: clean_translations ## pull translations via atlas detect_changed_source_translations: ## check if translation files are up-to-date i18n_tool changed -pre-requirements: ## install Python requirements for running pip-tools (still needed for scripts/*, which aren't on uv yet) - pip install -r requirements/pip-tools.txt - local-requirements: ## no-op; `uv sync` (used by the targets below) already installs -e . itself @true @@ -90,18 +87,7 @@ requirements: dev-requirements ## install development environment requirements # explicitly in compile-requirements below rather than through one generic # loop over a shared list. -define COMMON_CONSTRAINTS_TEMP_COMMENT -# This is a temporary solution to override the real common_constraints.txt\n# In edx-lint, until the pyjwt constraint in edx-lint has been removed.\n# See BOM-2721 for more details.\n# Below is the copied and edited version of common_constraints\n -endef - -COMMON_CONSTRAINTS_TXT=requirements/common_constraints.txt -.PHONY: $(COMMON_CONSTRAINTS_TXT) -$(COMMON_CONSTRAINTS_TXT): - curl -L https://raw.githubusercontent.com/edx/edx-lint/master/edx_lint/files/common_constraints.txt > "$(@)" - printf "$(COMMON_CONSTRAINTS_TEMP_COMMENT)" | cat - $(@) > temp && mv temp $(@) - -compile-requirements: export CUSTOM_COMPILE_COMMAND=make upgrade -compile-requirements: pre-requirements ## Regenerate uv.lock for the root project, and re-compile *.in requirements for the not-yet-migrated sub-projects above +compile-requirements: ## Regenerate uv.lock for the root project and all uv sub-projects uv run --no-project --with edx-lint edx_lint write_uv_constraints pyproject.toml uv lock ${UV_LOCK_OPTS} @@ -131,11 +117,6 @@ compile-requirements: pre-requirements ## Regenerate uv.lock for the root projec uv export --frozen --no-hashes --group dev --no-emit-project; \ } > requirements/edx/development.txt - sed 's/Django<5.0//g' requirements/common_constraints.txt > requirements/common_constraints.tmp - mv requirements/common_constraints.tmp requirements/common_constraints.txt - sed 's/pip<25.3//g' requirements/common_constraints.txt > requirements/common_constraints.tmp - mv requirements/common_constraints.tmp requirements/common_constraints.txt - @# requirements/edx-sandbox and scripts/xblock: single compat export, no dependency-groups. @for d in requirements/edx-sandbox scripts/xblock; do \ echo ; \ @@ -180,12 +161,12 @@ compile-requirements: pre-requirements ## Regenerate uv.lock for the root projec } > $$d/requirements/testing.txt; \ done -upgrade: $(COMMON_CONSTRAINTS_TXT) ## update all dependencies (uv.lock for the root project and all uv sub-projects) to the latest releases satisfying our constraints - $(MAKE) compile-requirements COMPILE_OPTS="--upgrade" UV_LOCK_OPTS="--upgrade" +upgrade: ## update all dependencies (uv.lock for the root project and all uv sub-projects) to the latest releases satisfying our constraints + $(MAKE) compile-requirements UV_LOCK_OPTS="--upgrade" upgrade-package: ## update just one package to the latest usable release @test -n "$(package)" || { echo "\nUsage: make upgrade-package package=...\n"; exit 1; } - $(MAKE) compile-requirements COMPILE_OPTS="--upgrade-package $(package)" UV_LOCK_OPTS="--upgrade-package $(package)" + $(MAKE) compile-requirements UV_LOCK_OPTS="--upgrade-package $(package)" check-types: ## run static type-checking tests mypy diff --git a/requirements/README.rst b/requirements/README.rst index c095490c06be..8b53f9f691cb 100644 --- a/requirements/README.rst +++ b/requirements/README.rst @@ -7,18 +7,15 @@ The main application's Python dependencies are declared in the root and ``[tool.edx_lint].uv_constraints`` for repo-specific version pins) and locked in the root ``uv.lock``, managed with `uv`_. -This ``requirements/`` directory now only holds: +This ``requirements/`` directory now only holds ``edx-sandbox``, its own +standalone ``uv``-managed project (``pyproject.toml`` + ``uv.lock``) for +Codejail's isolated sandbox environment. -- ``edx-sandbox``, its own standalone ``uv``-managed project (``pyproject.toml`` + - ``uv.lock``) for Codejail's isolated sandbox environment -- ``constraints.txt`` / ``common_constraints.txt`` / ``pip-tools.in`` / ``pip-tools.txt``, - now unused leftovers from the pip-compile era, pending removal (tracked in - `public-engineering#543`_) - -The three standalone script directories (``scripts/xblock``, +The three standalone script directories at the repo root (``scripts/xblock``, ``scripts/user_retirement``, ``scripts/structures_pruning``) each have their own ``pyproject.toml`` + ``uv.lock`` too, independent of both the main app and -each other. +each other. This completes the migration from pip-compile tracked in +`public-engineering#543`_. All of these are manipulated using the Makefile targets below in a Linux environment (to match our build and deploy systems); for developers on Mac, @@ -47,7 +44,7 @@ Want to upgrade just *one* dependency without pulling in other upgrades? You can Or, if you need to do it locally, you can use the ``upgrade-package`` make target directly. For example, you could run ``make upgrade-package package=ecommerce``. -If your dependency is pinned in constraints.txt, you'll need to enter an explicit version number in the appropriate field when running the workflow; this will include an update to the constraint file in the resulting PR. +If your dependency is pinned in ``[tool.edx_lint].uv_constraints`` (in ``pyproject.toml``), you'll need to enter an explicit version number in the appropriate field when running the workflow; this will include an update to that constraint in the resulting PR. Downgrade a dependency ====================== diff --git a/requirements/common_constraints.txt b/requirements/common_constraints.txt deleted file mode 100644 index 748858b7015a..000000000000 --- a/requirements/common_constraints.txt +++ /dev/null @@ -1,24 +0,0 @@ -# This is a temporary solution to override the real common_constraints.txt -# In edx-lint, until the pyjwt constraint in edx-lint has been removed. -# See BOM-2721 for more details. -# Below is the copied and edited version of common_constraints -# A central location for most common version constraints -# (across edx repos) for pip-installation. -# -# Similar to other constraint files this file doesn't install any packages. -# It specifies version constraints that will be applied if a package is needed. -# When pinning something here, please provide an explanation of why it is a good -# idea to pin this package across all edx repos, Ideally, link to other information -# that will help people in the future to remove the pin when possible. -# Writing an issue against the offending project and linking to it here is good. -# -# Note: Changes to this file will automatically be used by other repos, referencing -# this file from Github directly. It does not require packaging in edx-lint. - -# using LTS django version -Django<6.0 - -# elasticsearch>=7.14.0 includes breaking changes in it which caused issues in discovery upgrade process. -# elastic search changelog: https://www.elastic.co/guide/en/enterprise-search/master/release-notes-7.14.0.html -# See https://github.com/openedx/edx-platform/issues/35126 for more info -elasticsearch<7.14.0 diff --git a/requirements/constraints.txt b/requirements/constraints.txt deleted file mode 100644 index 2fe35fcd6841..000000000000 --- a/requirements/constraints.txt +++ /dev/null @@ -1,152 +0,0 @@ -# Version constraints for pip-installation. -# -# This file doesn't install any packages. It specifies version constraints -# that will be applied if a package is needed. -# -# When pinning something here, please provide an explanation of why. Ideally, -# link to other information that will help people in the future to remove the -# pin when possible. Writing an issue against the offending project and -# linking to it here is good. -# For further details on how to properly write constraints here please consult -# https://openedx.atlassian.net/wiki/spaces/COMM/pages/4400250883/Adding+pinned+dependencies+in+constraint+file - -# This file contains all common constraints for edx-repos --c common_constraints.txt - -# Date: 2025-10-07 -# Stay on LTS version, remove once this is added to common constraint -Django<6.0 - -# Date: 2026-01-13 -# We would normally pin celery to <6.0.0 to avoid auto-updating across a major -# version boundary without more thorough testing. The reason it's currently also -# pinned to !=5.6.1 is because of a celery bug related to the eta and countdown -# parameters. This bug caused operational issues in MIT's deployment. -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35280 -celery>=5.2.2,!=5.6.1,<6.0.0 - -# Date: 2020-02-10 -# django-oauth-toolkit version >=2.0.0 has breaking changes. More details -# mentioned on this issue https://github.com/openedx/edx-platform/issues/32884 -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35277 -django-oauth-toolkit==1.7.1 - -# Date: 2024-07-19 -# Generally speaking, the major version of django-stubs must either match the major version -# of django, or exceed it by 1. So, we will need to perpetually constrain django-stubs and -# update it as we perform django upgrades. For more details, see: -# https://github.com/typeddjango/django-stubs?tab=readme-ov-file#version-compatibility -# including the note on "Partial Support". -# Issue: https://github.com/openedx/edx-platform/issues/35275 -django-stubs<6 - -# Date: 2019-08-16 -# The team that owns this package will manually bump this package rather than having it pulled in automatically. -# This is to allow them to better control its deployment and to do it in a process that works better -# for them. -edx-enterprise==8.3.0 - -# Date: 2023-07-26 -# Our legacy Sass code is incompatible with anything except this ancient libsass version. -# Here is a ticket to upgrade, but it's of debatable importance given that we are rapidly moving -# away from legacy LMS/CMS frontends: -# https://github.com/openedx/edx-platform/issues/31616 -libsass==0.10.0 - -# Date: 2024-07-16 -# We need to upgrade the version of elasticsearch to at least 7.15 before we can upgrade to Numpy 2.0.0 -# Otherwise we see a failure while running the following command: -# export DJANGO_SETTINGS_MODULE=cms.envs.test; python manage.py cms check_reserved_keywords --override_file db_keyword_overrides.yml --report_path reports/reserved_keywords --report_file cms_reserved_keyword_report.csv -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35126 -numpy<2.0.0 - -# Date: 2023-09-18 -# Library is still in active development. Major versions require review -# from openedx-maintainers. Minor and patch versions can roll out automatically. -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35269 -openedx-core<2 - -# Date: 2023-11-29 -# Open AI version 1.0.0 dropped support for openai.ChatCompletion which is currently in use in enterprise. -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35268 -openai<=0.28.1 - -# Date: 2024-04-26 -# path==16.12.0 breaks the unit test collections check -# needs to be investigated and fixed separately -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35267 -path<16.12.0 - -# Date: 2021-08-25 -# At the time of writing this comment, we do not know whether py2neo>=2022 -# will support our currently-deployed Neo4j version (3.5). -# Feel free to loosen this constraint if/when it is confirmed that a later -# version of py2neo will work with Neo4j 3.5. -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35266 -py2neo<2022 - -# Date: 2020-04-08 -# Adding pin to avoid any major upgrade -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35265 -pymongo<4.4.1 - -# Date: 2024-08-06 -# social-auth-app-django 5.4.2 introduces a new migration that will not play nicely with large installations. This will touch -# user tables, which are quite large, especially on instances like edx.org. -# We are pinning this until after all the smaller migrations get handled and then we can migrate this all at once. -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/37639 -social-auth-app-django<=5.4.1 - -# # Date: 2024-10-14 -# # The edx-enterprise is currently using edx-rest-api-client==5.7.1, which needs to be updated first. -# edx-rest-api-client==5.7.1 - -# Date 2025-01-08 -# elasticsearch==7.13.x is downgrading urllib3 from 2.2.3 to 1.26.20 -# https://github.com/elastic/elasticsearch-py/blob/v7.13.4/setup.py#L42 -# We are pinning this until we can upgrade to a version of elasticsearch that uses a more recent version of urllib3. -# Issue for unpinning: https://github.com/openedx/edx-platform/issues/35126 -elasticsearch==7.9.1 - -# Date 2025-05-09 -# lxml and xmlsec need to be constrained because the latest version builds against a newer -# version of libxml2 than what we're running with. This leads to a version mismatch error -# at runtime. You can re-produce it by running any test. -# If lxml is pinned in the future and you see this error, it may be that the system libxml2 -# is now shipping the correct version and we can un-pin this. -# Issue: https://github.com/openedx/edx-platform/issues/36695 -lxml==5.3.2 -xmlsec==1.3.14 - -# Date 2025-08-12 -# The newest version of the debug toolbar has a bug in it -# https://github.com/django-commons/django-debug-toolbar/issues/2172 -# Pin this back to the previous version until that bug is fixed. -django-debug-toolbar<6.0.0 - -# Date 2026-01-13 -# Sphinx-autoapi changed the version of astroid it needs -# but the newer version is not compatible with the current pylint version -# which wants a newer version of astroid. This can be removed once we're -# building requirements with Python 3.12 -# https://github.com/openedx/edx-platform/issues/37880 -sphinx-autoapi<3.6.1 - -# Date 2026-03-02 -# setuptools 82.0.0 removed pkg_resources from its distribution, but fs (pyfilesystem2) -# still uses pkg_resources for namespace package declarations. This constraint can be -# removed once pyfilesystem2 drops its pkg_resources usage. -# https://github.com/PyFilesystem/pyfilesystem2/issues/577 -# Issue for unpinning: https://github.com/openedx/openedx-platform/issues/38068 -setuptools<82 - -# Date 2026-03-02 -# The latest version of pylint pins back astroid to an older version. -# This holdback is not caught in the docs requirements file and since both the docs -# and testing file are required in the development.in file, we fail to compile -# development.txt because of conflicting dependencies. -# -# Holding astroid back until pylint releases a new version that works with the latest -# version of astroid. -# https://github.com/openedx/openedx-platform/issues/38066 -astroid==4.0.4 diff --git a/requirements/pip-tools.in b/requirements/pip-tools.in deleted file mode 100644 index 5d4419ea4bc0..000000000000 --- a/requirements/pip-tools.in +++ /dev/null @@ -1,12 +0,0 @@ -# Just the dependencies to run pip-tools, mainly for the "upgrade" make target -# -# DON'T JUST ADD NEW DEPENDENCIES!!! -# -# If you open a pull request that adds a new dependency, you should: -# * verify that the dependency has a license compatible with AGPLv3 -# * confirm that it has no system requirements beyond what we already install -# * run "make upgrade" to update the detailed requirements files - --c constraints.txt - -pip-tools # Contains pip-compile, used to generate pip requirements files diff --git a/requirements/pip-tools.txt b/requirements/pip-tools.txt deleted file mode 100644 index 56ff83513ea3..000000000000 --- a/requirements/pip-tools.txt +++ /dev/null @@ -1,30 +0,0 @@ -# -# This file is autogenerated by pip-compile with Python 3.12 -# by the following command: -# -# make upgrade -# -build==1.5.0 - # via pip-tools -click==8.4.1 - # via pip-tools -packaging==26.2 - # via - # build - # wheel -pip-tools==7.5.3 - # via -r requirements/pip-tools.in -pyproject-hooks==1.2.0 - # via - # build - # pip-tools -wheel==0.47.0 - # via pip-tools - -# The following packages are considered to be unsafe in a requirements file: -pip==26.1.2 - # via pip-tools -setuptools==81.0.0 - # via - # -c requirements/constraints.txt - # pip-tools