Is Python installed on Mac?
Yes. And Apple has been warning that the pre-installed Python 2 binary, which has been part of the Mac system since Mac OS X Jaguar 10.2, will be removed in a "future version of macOS" since the initial beta release notes for macOS Catalina were released. Furthermore, Apple stated that scripting runtimes, such as those for Python, Ruby and Perl would no longer be included with future versions of macOS either. The guidance for developers being to include any runtimes their solutions are dependent on within their apps.
Why the need for this change?
As of January 2020, the organization that oversees Python development and releases officially sunset Python as of version 2.7 in favor of the newer, more secure Python 3 and subsequent versions. This means that updates, bug fixes and security updates will only support Python 3.x moving forward, as Python 2 has reached end-of-life.
While Python 3 is the official successor, updating Python code from version 2.x to 3.x is not a trivial undertaking. One simply cannot replace the runtime with a newer version and expect everything to "just work." The same is even true for the various minor versions of Python 3 that are currently supported in parallel, as evidenced by Python 3.7-3.10 being currently supported (as of this writing) while Python 3.11 is in beta.
In addition to the written warning to developers in the macOS release notes, Apple has gone the extra step to display informational messages when users attempt to use deprecated Python 2 runtimes in macOS Monterey. These warnings may be difficult for the end-user to understand, mainly being included to aid developers and admins in tracking down applications and scripts that require updating. Additionally included in the beta release notes for macOS Monterey 12.3, Apple states that the directory /usr/bin/Python will be completely removed.
In an effort to shore up security by removing deprecated programming runtimes from its flagship macOS – even with all the adequate warnings over the years – a removal of functionality at this scale in an update could lead to problems for users, admins and developers alike. Even though Apple has a well-documented history of adding features for end-users and management within their "Spring Updates", potential functionality breaking removals in a minor update are historically out of the norm and therefore, not expected.
Further complicating matters, the beta period for a minor update is much shorter (6-8 weeks) than the beta period for major system releases (4-5 months). This added wrinkle leaves far less time for developers and admins to update code, test updates and deploy them to user’s devices.
For example, the warning dialog boxes introduced in macOS Monterey forced most admins to update their scripts and tools to comply with the deprecation of Python 2.7. Nevertheless, calls to the legacy Python 2.7 run-time can appear in some unexpected places.
First, policy scripts and extension attributes in Jamf Pro may be written entirely for Python 2.7. You can identify these scripts with the #!/usr/bin/Python or #!/usr/bin/env Python shebang in the first line of the script. Shell scripts may also call Python to utilize certain system functionality. Laurent Pertois has a script which uses the Jamf API to search through all scripts and extension attributes for uses of the Python command. This should provide you a list of locations to check where Python usage is found.
Python in Installation Scripts
You will also frequently find Python scripts or calls in pre- and post-install scripts within installer packages. Since the pkgs are usually built by the software vendor, you may not be aware of these Python scripts at all. I have written a script called pkgcheck which recursively searches through a folder of installer pkgs and lists all the scripts that use a Python shebang or the Python tool in the code. Utilizing this script will definitely help with identifying third party installer packages that could cause trouble moving forward.
When you identify a pkg with a script that uses Python, it is helpful to notify the vendor that their installer will break with macOS 12.3 and later. Despite your best effort, if the software vendor is unable to provide an update in time, leveraging Jamf Pro’s Smart Groups to prevent the installation of this package on your Macs that have been updated to macOS 12.3 and higher can help workaround any issues that could negatively impact end-user performance. You can also attempt to update the affected Python scripts yourself and repackage the software for deployment, but depending on what the installation scripts do, that may be a difficult task.
Open-source tools for Mac admins are often written entirely in Python 2. You can identify them with the shebang, as mentioned previously. When the shebang is /usr/bin/Python, then it is using the built-in Python 2 which will subsequently fail on macOS 12.3. Checking the developers GitHub repository or website for the tool in question may yield updates or instructions to get these tools operational under macOS 12.3 and later versions. If you feel comfortable, you may also try asking for a solution from fellow Mac admins in Jamf Nation or the MacAdmins Slack channel for alternative solutions.
One example of the types of solutions that may exist for your particular issue is the DockUtil tool. While the developers are working on a new Python 3 version, an alternative tool can be found in DockLib, which already supports Python 3.
Long live Python 3
While Python 3 is not a drop-in replacement for Python 2, it remains the most logical step forward. There is a Python 3 binary in macOS, however, it is only a placeholder binary which either redirects to the Python runtime installed with Xcode or prompts the user to install the Developer Command Line Tools. The Python 3 binary included within macOS is not a good alternative to the deprecated Python 2.
As Apple recommended back in the macOS Catalina release notes, when you want a Python version you can depend on, the best solution is to provide your own.
The DockLib author recommends using the MacAdmins Python version. This open-source project provides a pkg installer for Python 3, preconfigured with a set of useful Python modules preinstalled. It also installs into a non-standard location in the file system to avoid conflicting with other Python versions that developers might be using.
This is a great solution when you want to continue to use Python for your admin tools. Another helpful option is to build your own customized Python with modules using Greg Neagle's Relocatable-Python tool.
Whichever Python you do end up using, remember that you are now responsible for maintaining and updating it, as well.
Even with the best preparation, this transition will generate some issues. You will have to check, update and verify your own scripts, along with notifying vendors and tool developers that they should update their installation packages to reflect the tool-breaking changes with the deprecation of Python 2.
You may have to rely on Jamf Pro and Smart Groups to defer installation of software and updates to apps that still utilize Python calls in macOS Monterrey 12.3. If the software is critical for your business, you may find that deferring the update to 12.3 is necessary until any Python 2-dependant software is patched. If you want to keep using Python for open-source or your own tools, following Apple's original recommendation of providing and managing your own version may be the best path forward.
Have market trends, Apple updates and Jamf news delivered directly to your inbox.