Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of macOS, scripting language runtimes won’t be available by default, and may require you to install an additional package. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
The question is: who wants to rewrite Homebrew in golang (or another compiled language)? What else will be affected by this move?
Photo by Rishi Deep on Unsplash
Latest comments (86)
I don't understand what you mean yet?
Interesting - for iOS this was always the case, ostensibly to prevent (or at least make harder) execution of things that aren't vetted through the app store or sandboxed in the browser. But this sort of supply chain control doesn't exist for macOS devices, so I guess they are simply reducing the support pain of all these moving parts and making them the developers problem? Perhaps instead they'll concentrate on supporting a decent package manager.. with an open ecosystem like Nuget or PsGallery, or one of the mainline Linux distros (Debian fan here)...
Full disclosure: never owned or operated a Mac since the Classic back in '92 that was on my desk when I got my first job drawing flow diagrams for speech systems.
Scripting languages may mean interpreted, and those include Javascript, HTML, Bash, Python, Ruby, Perl, make, awk, sed, Regexp engines embedded in grep, vi(m)'s config language, ... the list goes on and on and becomes esoteric at times. It's unclear to me why some might be chosen for elimination and not others. But I hope they go down this path while simultaneously producing ever worse keyboards; I need more people in my organization to push back and select a Linux based laptop for the good of those of us who have resisted the org's desire to optimize for IT rather than for those of us producing the code that provides the services we sell. Devs with Macs are almost cliche. I'd love for that to not be such a ubiquitous way of life.
I don't know what all you are arguing about. They just remove preinstalled out-dated packages, which, as a dev, everyone prefer not to use and always installing a replacement like rbenv, python3. Homebrew already did check if ruby isn't available, then download it, as for old MacOS and Linux system.
Just download ruby if not found. They already did that.
I, for one, welcome this move
One of the difficulties with getting started as a Python or Ruby developer on macOS is coming to terms with globally installed interpreters and packages, and how these can clash with those in your projects
It also means there won't be future compatibility problems with interpreters being end-of-life'd, as in the case of Python 2.x
Mwa-ha-ha.
Did they rewrite xattr (and maybe other system tools) to avoid python already?
I think javascript is kinda important... also there are a bunch of good programs coded in python ie. Blender
Comes down to the old adage - 'control the ENTIRE stack'
This way nothing can harm what you release(permit) ....
Doesn't seem like a huge deal to me.
I don't use all those languages, but the bundled version was usually an older one. More often than not you couldn't use it, and I just ended up installing the latest anyway.
Pretty sure most (if not all) have macOS installers.
They're not saying those languages are legacy, they're saying (other) legacy software is dependent on those pre-installed runtimes.
Seems to me like they're just not going to provide a decrepit version by default anymore. They're not pre-installed on all Linux distros or Windows. Seems like a sane thing to do to me.
Python 2.7.10 (2015)
Perl 5.18.4 (2014?)
Ruby 2.3.7 (2018)
So, not that old- especially Ruby.
I guess the point is the title makes it sound like Apple is "banning" scripting languages, which is not the case.
Not bundling Python 2.x certainly makes sense, but that doesn't mean they should be dismissing bundling Python 3. Updating the runtimes is the only thing that makes sense...every other UNIX-like system does exactly that.
The issue, I believe, comes to when you have to ship to the end-user. In my experiencing, installing runtimes on Apple is not a piece of cake by default. A lot of non-tech-savvy users won't be willing to follow a long process to get some weird thing called (say) "Python" installed, just so they're able to run software. It's not like on Windows, where you only have to run a simple installer script...unless something has profoundly changed in the past year on the Apple ecosystem?
Now, sure, you can bundle the runtime, but this is an additional Apple-targeted packaging step that can be a pain in the butt for the developer.
It's practically impossible (although not technically) for Apple to block these languages from the platform altogether. The way I see it, this is the strongest action they can cook up a psuedo-justification of, wherein they discourage use of the language.
Pretty amusing that AppleScript isn’t included in the list of legacy scripting language runtimes as it is probably the only one which actually is a legacy scripting language.
Rust could be a good fit.
This is exactly what I was thinking. Please get them out of my way so I don't have to remove them or try and get them out of my PATH. If you're going to install Homebrew, it's not much harder to also install Ruby or have the project do so for you. Linux distros don't come with tons of scripting languages, you have to install most of them if you want them.
This will be slightly annoying for my job, where I have to use a Mac, I guess. But since almost everything I do runs inside docker containers which don't have this problem, I don't really care.
Apple can do whatever they want with their OS. It's not a development platform, it's a consumer desktop environment, and getting rid of obsolete versions of software makes sense, right? So they should ditch the version of bash they use that's from the 12th century. Except they can't because newer versions use licenses they don't like.
So rather than maintain semi-recent versions of software that's better served by containers, or old versions because of political reasons, just get rid of them. Most of the users won't notice.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.