macOS 10.15 Catalina Deprecates UNIX Scripting Languages

Python featured image.

The older Python language, version 2.7, is being deprecated in macOS 10.15 Catalina and won’t be included in macOS 10.16. The same goes for other UNIX scripting languages.

Let’s focus on Python first because of its nuances of versions.

The Python Case

This is not as bad as it sounds. Python 3.0 was released way back in December, 2008. Python 3.0 made a fundamental break from some bad design choices in Python 2.x, which culminated in version 2.7. Accordingly, a lot of complex Python 2.x code just won’t run with Python 3.x and has to be rewritten.

But Apple never updated the default install in macOS and left Python at version 2.7 for longstanding backwards compatibility. For 10 years, it has been left up to users to install Python 3.x, a version which can be installed alongside of 2.7. The user then gets to select the environment. For all the details one this, see:

[How to Upgrade Your Mac to Python 3 [2017 Update]]

One way to look at this is that so long as users who needed Python 3.x could easily install it, there was no need or Apple to continuously manage a new version in each release of macOS starting in 2009. [The latest Python version is 3.7.3]

Apple’s Deprecation Statement

Knowing all this, we can now put Apple’s developer notes for 10.15 Catalina into proper perspective.

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)

Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)

The bottom line is that you’ll still be able to install UNIX scripting packages like Perl, Python and Ruby into future versions of macOS, just as you could in the past. They just won’t be included by default in macOS 10.16 and beyond.

The advantage of this is that most Mac customers never use UNIX scripting languages, let alone drop into a UNIX shell. Apple won’t have to ship macOS with older versions of these languages. And I’m guessing it’s a security consideration. Also, note:

[RIP Bash: macOS Catalina Will Set Z Shell as Terminal Default]

So it’s not really a big deal. Apple isn’t abandoning the UNIX underpinnings of macOS. Experienced UNIX users will be able to install what they need.

I predict, however, that one day in late 2020, a scientist will take delivery of a new Mac, open a Terminal window, and find Python (… Perl … Ruby) missing. There will be wailing and gnashing of teeth.

Send him/her to this article.

[Editor’s note: And perhaps also send them to Homebrew, should we all be fortunate enough that it remains in active development for many years to come!]

10 thoughts on “macOS 10.15 Catalina Deprecates UNIX Scripting Languages

  • In the past when Apple took something away – e.g. floppy drives and optional drives – they had replaced it with something better.

    I bought my first Mac because the system was the first UNIX I had used that had a useable GUI and professionally written software. Each year, macOS and the Mac becomes less UNIX. It’s becoming hardier to justify why someone should consider a Mac over Windows.

    At some point in the future, I expect the very near future, Apple will remove Terminal and will lock us all into the App Store. We may switch to running Raspberry Pi just so we can have a machine to learn scripting languages and install open source software. Computing destiny will be fulfilled.

  • While the Old UNIX Guy in me is disappointed at this, when I think about it I have to admit it makes sense at a certain level. After all, of the 20 million+ Macs that Apple sells this year, how many of them will ever run a Python script – either directly or indirectly?

    It reminds me of back 15 years or so ago when Apple stopped shipping X11 as part of MacOS X and made it an optional download for those few of us who needed it.

    As long as Apple keeps giving us a Terminal.app and a way to install Homebrew, I can get what I need as I become an even Older UNIX Guy…

  • Regarding security, it’s a nightmare for every app to ship with its own scripting language runtime. Then a security bug requires patching every single app that uses a language rather than a single OS update.

  • This is unfortunate. Scripting languages a key part of Unix’s appeal. I may not use awk and perl much, but they are standard tools that many applications depend on.

    Python 3’s worst mistake was breaking backward compatibility with Python 2. One of the most egregious and unnecessary examples of this was removing the print statement – a useful and user-friendly piece of syntax that harkens back to BASIC – and replacing it entirely with an incompatible print() function, instantly breaking the vast majority of Python 2 programs in a very annoying way.

    1. Python 3 could have kept the print statement as an option (or kept it as standard syntax alongside the new print() function) but ideological purity seems to have trumped practicality and convenience for the programmer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.