RedHat & Debian End Support For Python 2
It’s been more than four years since the Python Software Foundation (PSF) sunset Python 2. Since then, commercial support options for Python 2 have gradually disappeared despite the fact that some organizations who have yet to migrate their Python 2 applications need it more than ever given the recent high profile vulnerabilities:
While the vast majority of organizations have moved on to Python 3, there are still millions of daily downloads of Python 2:
Source: pypistats.org
Obviously, there are still some organizations deriving value from Python 2, and likely counting on security patches from their OS vendor (who are the only still providing support at this point in time) to keep things running securely. But with the most popular Linux distro (Ubuntu) having sunset Python 2 support last April, and the next three most popular distributions ending their support in 60 days, things are coming to a head:
- Debian — v10 (Buster) was the last release to include Python 2.7, which will end support in June 2024.
- CentOS — v8 was the last version to include support for Python 2.7, which will be EOL in May 2024.
- Red Hat Enterprise Linux — RHEL 8 was the last version to include support for Python 2, which will be retired in June 2024.
In other words, if you’re still running a mission critical Python 2 application, your vendor choices for support and security patches are fast disappearing. While we always advocate the need to evaluate when it makes sense to migrate, that time is likely now.
Automating Migration from Python 2 To Python 3
ActiveState is the only commercial vendor that continues to patch and maintain a version of Python 2.7.18. Based on that distribution, we’ve been providing support for a number of organizations that are still generating value from their Python 2 applications.
While no company wants to remain on a dead language if they can help it, our customers’ reasons for remaining on Python 2 generally fall into three categories:
- Unable to migrate due to a critical Python 2 dependency
- The need to support key customers, who are unable to migrate to a newer version
- Their business case for migration continues to be too weak to justify the costs
Typically, we’ve found that it’s the opportunity cost of migration that principally holds organizations back. After all, time and resources spent on migrating a legacy application is time and resources not spent on improving that application to beat your competition. And even after migrating, you’re merely back to where you started from with no new differentiating features or functionality.
One way to avoid this trap is to outsource the migration work, trading off time and resources for budgeted dollars. As Python experts, ActiveState can help you not only migrate your application, but also support it during that process AND keep it current going forward using a process that minimizes breaking changes.
For example, we’ve learned that the further the jump (e.g., Python 2.7 to Python 3.12), the more your dependencies will have changed, resulting in too much broken code/code revisions than can be reasonably dealt with:
Instead, our process involves a multi-step migration (e.g., Python 2.7 -> Python 3.8 -> Python 3.10, etc) that limits the amount of code that needs to be fixed at each step. Some code fixes may be straightforward, while others might require input from your team. But if you’ve got a GitHub repository and decent code coverage in place, it’s possible to automate much of the migration at each step, dramatically lowering the opportunity cost of getting current.
Once you’ve migrated to a recent version of Python, you can use the same process to stay current so you never get stuck on an EOL version again. In other words, you’ll be able to upgrade to the next release of Python (or n-1, or n-2 or wherever you feel comfortable) without breaking your application.
If this looks like something you can take advantage of, please Contact Us to get started today.
Next Steps:
Watch our webinar on Walking Dead Past Python EOL to learn how you can minimize the opportunity cost of getting current and staying current with your Python application.