/
Quarterly Platform Constraints Audit

Quarterly Platform Constraints Audit

As of April 2026 an issue will automatically created in openedx-platform to audit the constraints files that feed into the platform Python requirements files. Constraints are added as a way to mitigate problems with specific upstream package versions that may have bugs or incompatibilities with other packages that we rely on. In a very few cases, such as Django, we lock major versions across the Open edX ecosystem to ensure compatibility between our own packages and openedx-platform. Those pins are handled via a separate process and can be safely ignored for this audit.

The goal is to make sure there is a cadence for reviewing these temporary constraints so that we can remove them before they become emergency conflicts, security concerns, or block using new features.

There are two places to check:

https://github.com/openedx/openedx-platform/blob/master/requirements/constraints.txt

https://github.com/openedx/edx-lint/blob/master/edx_lint/files/common_constraints.txt

With the exception of the Django pin, which gets handled separately, each constraint listed should have the date it was added, a link to an issue, description of why it is needed, and the conditions for removal. For each issue the on-call should do the following:

  1. Starting with the oldest pins, review the description in the file and linked issue

  2. Check if the conditions for removal are met

    1. If not, add a note to the ticket that states you did the review and update with any new information on why it is blocked and when removal can happen

    2. If the constraint can be removed:

      1. Take ownership of the removal ticket and comment that you are moving the removal forward so that anyone following the ticket can see that it is in progress

      2. If you are comfortable working with platform code you can remove the pin yourself, using the directions below, if not you can ping the #core-contributors channel describing what you’re doing and ask for help

When you’ve reviewed all of the constraints, update the quarterly audit issue with any actions taken or updates made and close it.

Removing an edx-lint constraint

The edx-lint constraint file is downloaded into many repositories as part of their package upgrade process. Currently there are only 2 constraints in there, so it shouldn’t be necessary to make changes most of the time. It is probably best to reach out to #ask-axim on Slack for help if you think one of them is ready to be changed or removed.

Removing an openedx-platform constraint

Depending on what the constraint is, you may need to get help from maintainers of other repositories to get new versions merged there first before the one in openedx-platform is unblocked. In these cases it is also fine to ask those repository maintainers to complete the removal once a new version of their package is released.

If the dependency is in openedx-platform itself, in most cases you can follow any steps in the constraint removal issue, including adjusting any requirements/*.in files, running make upgrade locally in the same version of Python that the current openedx-platform is compatible with (requirements/base.txt says the version we’re generating with at the top of the file).

  1. Create a python vitrual environment with the correct version if you don’t have one

  2. Make your *.in and constraints.txt edits. Do not make changes to common_constraints.txt as that is the file that comes from edx-lint and will be overwritten. Do not make changes to any other requirements/*.txt files as they will be overwritten.

  3. Run make pre-requirements to get the current versions of pip-tools

  4. Run make upgrade to get the new unconstrained versions of packages

  5. Check the diffs to make sure your expected changes are present. It’s likely that there will be other packages upgraded as well, this is normal. If there are diffs that include the python version in the header, your virtual environment is the wrong version and you will need to start again.

  6. Create a draft pull request to run tests against the new dependencies

  7. If everything passes, take the PR out of draft and ask for reviews

  8. If there are issues that you need help debugging reach out for help

In either case, reviews or help can come from Slack #core-contributors or, if there is no response there, #ask-axim .

Thanks for your help keeping the platform safe and stable!