Handling Outdated Dependencies

Owned by Jeremy Bowman (Deactivated)
Last updated: Feb 06, 2023
2 min read

Each time we perform a major Python/Django/etc. upgrade, we inevitably find a few dependencies which haven’t added support for the new version in a timely manner (or have ceased to be maintained altogether). These cases can require a lot of communications and/or effort, and hence should be started early in our upgrade process. Our preference is to stay on external dependencies which are actively maintained and support recent versions of the languages and frameworks we use, but each upgrade cycle a few packages which used to match that description are effectively abandoned. Our rough preferences on how to handle such cases are as follows:

  1. Ask the maintainer to create a new release containing any already-merged changes to support the version we’re upgrading to (and help resolve any concerns preventing that, if necessary). Often adding a GitHub Issue to request a new release works best for this (or commenting on an existing such issue, if one exists, to ask for a status update).

  2. Switch to an existing, more actively maintained equivalent package if that can be done with minimal effort. Often this is a fork made after maintenance of the original package ceased; the Insights->Network page of a GitHub repository is usually a good place to look for these, as is the project’s own issue tracker: open issues like “Is this package still maintained?” will often mention alternatives in the discussion, if any exist.

  3. Help to get merged any existing PRs adding support for the version we’re upgrading to (fix tests, respond to maintainer concerns, etc.)

  4. Create a new PR adding support for the version we’re upgrading to, and work with the maintainer to get it merged. This can take a long time depending on the maintainer’s availability, so these PRs need to be created early when needed.

  5. Review our usage of the dependency, and try to stop using it. This may involve refactoring our code such that we no longer need the dependency, or perhaps copying a small chunk of code from it if that lets us stop using the rest of it.

  6. Fork the package into the edX GitHub organization and apply the necessary updates. This is often the last resort if all of the options above fail to succeed in a reasonable length of time.