52 ms·

macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

435 points by undefined1 7y ago

exabrial 7y ago
I think that's ok, most everyone installs homebrew
- sys_64738 7y ago
  Including macOS developers!
- jeremyjh 7y ago
  How do you install homebrew without Ruby?
  - AlexeyBrin 7y ago
    You basically rewrite the current Ruby installer in a shell script that will download a Ruby version from Homebrew ...
  - exabrial 7y ago
    Pkg file...
    - foobiekr 7y ago
      encoded and embedded in a bash script, more likely.
- robin_reala 7y ago
  Right, but homebrew is written in Ruby. So there’ll need to be some more bootstrapping stages to install a recent Ruby first. Although it looks like they’ve got a plan: https://twitter.com/machomebrew/status/1136249501252038662?s=21 https://twitter.com/machomebrew/status/1136249501252038662?s...
- mixmastamyk 7y ago
  They should choose a package manager.
  - wahern 7y ago
    It's called the App Store.
    - saghm 7y ago
      You can't install Ruby/Python from the App Store
      - saagarjha 7y ago
        …yet.
        vortico 7y ago
        and probably ever. It's not the right tool for the job, unless Apple really does some restructuring.
- fooblitzky_bias 7y ago
  "I think that's ok, most everyone installs homebrew" Most everyone who doesn't know better. Brew is a trainwreck that breaks critical functions in macOS.
  - saagarjha 7y ago
    To be fair, Homebrew usually tries to not do this :)
Reedx 7y ago
Seems like a good move. Less cruft and don't have to deal with managing versions between the one you want and the one already on the system.
- xmichael999 7y ago
  I can't recall using the built-in version in ages, it is pretty much always homebrew before you even start. So I think this is a great move.
  - rrix2 7y ago
    How is homebrew installed?
    - grzm 7y ago
      https://brew.sh https://brew.sh
      - aquabeagle 7y ago
        Right... /usr/bin/ruby -e ...
        Operyl 7y ago
        Oh my god, it's the end of the world, Homebrew will never be able to make another installer that doesn't use ruby ever again! /s But let's be real, they're either going to make a .pkg, or just use a shell script or .. really, there's dozens of ways. They've been using an alternative version of ruby packaged in the homebrew folder for a while now. The only part of the process that requires System Ruby is the installer, now.
        delinka 7y ago
        https://www.ruby-lang.org/en/documentation/installation/#building-from-source https://www.ruby-lang.org/en/documentation/installation/#bui...
ihuman 7y ago
Does this include AppleScript and the Javascript runtime for AppleScripts? They reference Script Editor in the section above, so I'm assuming they're safe. Also, what's the best way to install homebrew if you don't have a system-level ruby? The current installer is a ruby script. Is it possible to get some sort of ruby-bootstrap that can install homebrew and a homebrewed ruby?
- olliej 7y ago
  No - the problem with the misc other interpreters is that they don’t provide sufficient binary stability for Apple to simply include the newest one in every update (which I suspect they would happily do). They’re not removing the commandline (although moving to zsh? :-/), or banning interpreters. They’re just not including them built into the os anymore. As for the AppleScript and JavaScript questions: Apple makes the runtimes for those, and makes sure they remaining binary compatible. Take a program that linked to (and used) the javascriptcore api to add js support. Something compiled 10 years ago will run without recompilation. Thats the bar for stability.
  - ihuman 7y ago
    I think you read more into my question than what I meant. I was asking literally about the best way to install it was without a system level ruby. Once you have homebrew, you can install ruby; but what about before that? Download and install ruby from ruby-lang.org, install homebrew and a brewed ruby, then uninstall the one from ruby-lang.org?
    - azinman2 7y ago
      I’m guessing home brew will end up creating a packaged installer than includes a home brew upgradable ruby
      - saagarjha 7y ago
        I'd think a script that you pipe into a shell with admin privileges is more likely ;)
DividableMiddle 7y ago
This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.
- new_realist 7y ago
  Does OSX offer reasonable container technology? chroot?
  - wedn3sday 7y ago
    Singularity recently released a (non-fully featured, but still useful) mac version.
  - pram 7y ago
    macOS has a native hypervisor framework, Docker and xhyve uses it. https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit https://github.com/moby/hyperkit
    - AceJohnny2 7y ago
      In other words, nothing serious. Does anyone actually use Docker on Mac? Xhyve is more of a proof-of-concept than a production-ready tool.
      - abhorrence 7y ago
        I use Docker on Mac, and know many others who do as well.
      - RussianCow 7y ago
        > Does anyone actually use Docker on Mac? What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.
olliej 7y ago
Probably the right call - many of them don’t have abi or api stability guarantees, or in the case of python needlessly broke backwards compatibility that is still causing pain today. Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work. The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update? People ship out of date libraries because updating requires changes beyond just pulling a new binary requires more work than the gain will give them. It’s part of why companies like Apple and Microsoft care so much about backwards compat: they want people running the most recent OS possible, and they don’t want people to avoid updates. Every time an update breaks something for anyone, they hold off updating in future. On the other side, developers don’t want to invest time and money into a feature that they don’t think will work/cause their app to crash in future.
- userbinator 7y ago
  It’s part of why companies like Apple and Microsoft care so much about backwards compat Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility. You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're willing to restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too, then it goes back to the early 80s.
  - valleyjo 7y ago
    Completely true. Apple only cares about back-compact down to a few older major versions. So often the big projects (like modern apps, Windows 10 S, etc) Microsoft does fail or struggle to gain traction IMO because of the blessing and curse of their back-compat requirements.
    - DaiPlusPlus 7y ago
      Those big-projects you mentioned failed to gain traction in the first place - with a tiny use-count for (e.g.) UWP vs Win32 it’s easy for MS to not take back-compat as seriously.
mutt2016 7y ago
Wait.. So I'll have to install Ruby before I can install Brew? Ok. Ruined 2 minutes of my day.
- azinman2 7y ago
  Except it’ll be the latest, and then easily updatable after that. Expect package installers that make the whole thing easier and more secure (signed packages vs a curl | /bin/sh)
- dwaite 7y ago
  I expect homebrew to switch to installing their own local ruby via a zsh. They already install their own local ruby today, but use the system-ruby as an entrypoint.
- rgovostes 7y ago
  Good point. Hopefully the Homebrew installer script will bootstrap this for you. They already build and distribute binary packages, they probably can easily download the existing Ruby package and execute it.
- nicky0 7y ago
  You install Brew every day?
AceJohnny2 7y ago
Fucking finally! Between this and deprecating Bash [1], I'm glad macOS is dropping all these obsolete packages it's been including (Emacs soon?). Their antiquity mean they're more of a hindrance to proper development than help. Now, if they'd officially endorse one open-source packaging solution as an alternative, I'd be fully satisfied. [1] https://news.ycombinator.com/item?id=20090193 https://news.ycombinator.com/item?id=20090193
- rgovostes 7y ago
  MacPorts has or had semi-official status. It was hosted by macOS Forge, which was an official Apple site that included other projects such as XQuartz. I'm unclear on the current status.
  - AceJohnny2 7y ago
    MacOS Forge has been deprecated for years (2016?), all its hosted projects have moved off. I don't think Apple has done anything for MacPorts since then, so I wouldn't consider it a current endorsement.
  - selectodude 7y ago
    Its a shame MacPorts kind of died on the vine. It just seems so much cleaner and less hacky than Homebrew.
    - AceJohnny2 7y ago
      It's not dead! [1] I use it daily, and it's working just fine. For example, check out the (centralized) list [2] of Ports files that define the packages. You can see it's pretty lively But your perception that it's dead is certainly symptomatic of an issue for the project. [1] yes yes Monty Python [2] https://github.com/macports/macports-ports https://github.com/macports/macports-ports
    - hnarayanan 7y ago
      It’s not dead. I too have used it nearly daily for over 15 years.
thrower123 7y ago
So, what's the point of using Macs as a better Linux, if they are continuing to strip out the parts of Linux that are useful? Might as well use WSL or Cygwin and save a bunch of money.
- dwaite 7y ago
  This is a great move. It will be two lines of code and two minutes to install the interpreter you need, and you will no longer be tied to a global, possibly ancient system version. Likewise, you won't have your own installed applications break on update because (for example) python2.7 was EoL and dropped from the OS. Installing your own instance of python or ruby should be two lines and about two minutes assuming a decent internet connection.
- zapzupnz 7y ago
  You do realise that the reason these things are being stripped out is because macOS includes hideously old versions for backwards compatibility with older software that depended on them, right? There is no real loss here; no sane users would use the built-in versions due to their age. It has been preferable to download and install newer versions for a long time, this changes nothing. And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows, then it's surely also no effort at all to install Homebrew or MacPorts (or other) — with the benefit of not working in a contrived, separate environment. This comment betrays a fundamental lack of understanding of modern developer workflows in macOS and feels just slightly like a troll comment from someone who likely doesn't use macOS to begin with.
  - wahern 7y ago
    > And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows Well, plenty of people use macOS precisely because it was like a more consistent Linux out-of-the-box. Apple will lose a ton of mindshare; indeed, they are losing a ton of mindshare. They've been slowly deprecating things for years, now, and leaving the rest to rot, and open source developers are increasingly drifting away. About 10 years ago macOS and Apple hardware started becoming the preferred kit for open source developers, and this showed--Apple kit was seen everywhere in Silicon Valley and eventually became the default kit given out by big software companies. That was all because of macOS' Unix personality. That's all going to change over the next several years. I was surprised when WSL 1.0 debuted. By making Linux _native_ on Windows, it solidified Linux' position as the dominate server-side platform. I'm not at all surprised they're ditching it for WSL 2.0, which is just Linux in a VM with a networked filesystem, precisely what people have been doing for about 15 years, keeping it solidly second class--like running Windows on macOS.
ytch 7y ago
I thought it is reasonable. IIRC, my MacOS 10.14.5 has python 2.7.10 built-in (I've install home-brew on it, but I guess it is the Apple built-in version), it is too old (Release Date: May 23, 2015).
NelsonMinar 7y ago
So what about shell scripts?
- saagarjha 7y ago
  Apple will have to ship with a POSIX compliant shell if they'd like to keep their UNIX® certification.
markstos 7y ago
Interesting that some version of Python will still retain a default status, while Perl and Ruby are both being removed from the default install. Congratulations, Python 3!
- briandear 7y ago
  That’s because no ruby developer ever depends on system ruby. It superfluous, not a vote for python.
snowoutside 7y ago
With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.
- cprayingmantis 7y ago
  The down side to that is that ruby is currently required to install Homebrew.
  - andoriyu 7y ago
    Just rewrite it in rust.
  - drivingmenuts 7y ago
    There will be a .pkg for that, if there isn't already.
    - george_perez 7y ago
      They seem to package a portable ruby already. https://twitter.com/MacHomebrew/status/1136249501252038662 https://twitter.com/MacHomebrew/status/1136249501252038662
  - month13 7y ago
    Could also just use bash to bootstrap an environment, like how RVM does.
  - dsl 7y ago
    You already need Xcode to get Homebrew working, and that will most likely be the vector by which optional scripting languages will be installed.
    - saagarjha 7y ago
daemonhunter 7y ago
Had to get rid of something to make way for those $1000 monitor stands.
chunsj 7y ago
Oh, please remove them ASAP or include the most recent version of them.
bla3 7y ago
I don't understand why everyone is so excited about this. I don't like using brew. I use a Mac because things just work. It was annoying that the system versions were old, but most of the time they were still workable. To me, this is another (admittedly small) thing I liked about the Mac that's going away.
- olliej 7y ago
  The problem is accruing security flaws (increasingly difficulty to back port fixes), and also the problems that come up when you install a different version (lots of Software just assumes it can use the same system python, which causes issues when it isn’t the archaic version).
  - bla3 7y ago
    I'd prefer if Apple took care of security fixes instead of some third party. And they could ship newer versions if keeping the old ones secure is harder.
    - olliej 7y ago
      The problem is that updating to a new version isn’t possible if it breaks existing software - what happens is that the end user experience is “I installed these updates and Apple broke my program” so don't update in future, and tell others not to as well. The only way to stop the OS from including out of date software and libraries is to not ship them if they don’t have stable abi. That’s what Apple is doing: it can’t reasonably ship them and keep them up to date, so it is going to stop.
      - jdsully 7y ago
        Doesn’t removing them have the same issue? “My software dependent on this ancient python no longer works - because there’s no python anymore”
        olliej 7y ago
gerbilly 7y ago
It might be nicer if they curated more up to date versions instead, but of course it's easier to remove things than to carefully manage dependencies. I'm not a big fan of brew however. Last time I checked it didn't seem to work well when switching between users.
ken 7y ago
Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid. (As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.") Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them. They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.
- drivingmenuts 7y ago
  A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system. If I'm not mistaken, current best practice is to somewhat isolate third-party developer software anyway, using homebrew, a VM or other solutions (not sure about Docker - don't use it). I can see where it would be an issue with developing for MacOS or iOS, but third-party web development doesn't really need anything that is installed on the system, and in my experience, it's actually better not to base it on the MacOS default packages.
  - Wowfunhappy 7y ago
    Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions. It doesn't use a container or anything like that. Certainly not a full-on VM. Maybe I'm old-fashioned (feels weird to say that as a 25-year-old, but here we are), but I quite like not having everything be in a container all the time.
shereadsthenews 7y ago
Civ IV will never work again. RIP.
- Marsymars 7y ago
  As a huge fan of Civ IV, I've found the macOS version pretty janky. I have a generally better experience on my Mac by just using Steam In-Home Streaming from my Windows box.
- mthoms 7y ago
  Why is that?
- nottorp 7y ago
  It uses the system python? I doubt it.
  - shereadsthenews 7y ago
    It absolutely does and macOS has already broken it several times. This I guess to some extent demonstrates the folly of having one. https://forums.civfanatics.com/threads/how-to-get-civ4-bts-working-on-el-capitan-and-sierra.549923/ https://forums.civfanatics.com/threads/how-to-get-civ4-bts-w...
lenkite 7y ago
Ok, this means homebrew needs to be compiled to a native binary!
- yellowapple 7y ago
  Or a shell script.
- deleted 7y ago
  [deleted]
Godel_unicode 7y ago
It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". One more piece of evidence that Microsoft cares about developers more than Apple does.
- pcr910303 7y ago
  Well, python 2.7.5 isn’t ‘modern’ python... AFAIK :-)
  - Godel_unicode 7y ago
    Not sure what that version number has to do with anything...? The Microsoft package is 3.7 Edit: 3.7.3, specifically.
- grumpydba 7y ago
  > It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". You still need admin rights and an internet setup. Linux is still king.
  - Sharparam 7y ago
    On what system can you install python without Internet access?
    - grumpydba 7y ago
      On Linux you don't need to install it it is there by default on all major distros.
jzl 7y ago
I'm trying to understand how these two points reconcile. "Future versions of macOS won’t include scripting language runtimes by default" and "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." If Catalina is the last version with any scripting languages at all, why bother with the second point? Or will python3 still be available in the future despite point 1?
- jaabe 7y ago
  As I understood it, scripting languages will still be available to the user, they just won’t have ancient versions preinstalled. Of course that also means you can’t rely on them being installed at all as a developer. Which means you should start bundling the stuff you need to run your app, and, they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient.
  - jzl 7y ago
    Ok, I guess it's worded vaguely enough to allow for the possibility of optional installation ("by default"), even though they don't outright promise that they'll offer a way to install it. (I interpreted it in the same way as "macOS doesn't include Photoshop by default".) Having it come from the app store doesn't seem totally appropriate since it would need to do more than dump a bundle into /Applications, like making some /usr/local/bin symlinks. Maybe they'll allow themselves that exception. "they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient" --> Right, I couldn't figure out if that's all they meant. Valid point or not, it doesn't seem appropriate to make it in the context of those notes. If you're going to make me bundle the language anyway, don't also give me a lecture about which version to use. :)
    - wtallis 7y ago
      I suspect they plan to distribute the scripting languages the same way they currently handle the command line developer tools package, where the OS offers to download and install the package the first time you try to run one of those tools.
zmmmmm 7y ago
How deep you are willing to go with conspiracy theories ... If one was planning to kill off all non-approved software on an OS, what would you do first? Remove all the runtimes that can execute unapproved software of course. Then you are free to impose signing as a requirement for applications and a mandatory app store, and reap the 30% rent tax forever more. Is Apple doing that? Of course, we can't tell. There are lots of good reasons to do this that aren't evil. The best evil plans are indistinguishable from good plans but just happen to have evil outcomes that are in your interest.
- saagarjha 7y ago
  It is trivial to package a scripting runtime with an App Store application; so trivial, in fact, that a number of apps for iOS do this already.
  - zmmmmm 7y ago
    That doesn't really contradict anything above. It still remains true that if they were planning on removing ability to run unapproved applications from OSX, the first step would be to take out the ability to do that which is installed by default. Restricting what App Store applications can do would come later (and be controlled by policy rather than technical limitations).
deleted 7y ago
[deleted]
bayareanative 7y ago
Not a big deal. Anyone doing serious development at scale would mirror production anyways (12factors principle). Plus, who uses Apple's obsolete junk anyhow? For a very long time, homebrew and macports has solved Apple macOS not rolling releasing terminal-based packages. Teapot tempest.
mahgnous 7y ago
Doesn't need to have them included at this point. I'd much rather install them manually.
TimTheTinker 7y ago
I think this is great, but at the same time, auto-installing homebrew ought to be an option (perhaps enabled by default) when installing the “XCode command line tools”. Better yet, offer a “developer setup” app that sets up the command line tools, homebrew, iTerm2, updated bash/zsh, and more. Apple would do best to pave the cow paths developers have already worn into macOS, especially when it comes to command line utilities. A dev setup app would just make it quicker/simpler and pave the way for newbies to get into development.
- jarcane 7y ago
  Homebrew is not the only package provider for MacOS.
  - reikonomusha 7y ago
    Would Apple be in the wrong simply being opinionated about using Homebrew?
    - hasahmed 7y ago
      Yes
      - csomar 7y ago
        I'm not sure why you are getting downvoted. I'd not like it if Apple will opinion-ate and make any package manager a default. Package managers are for software developers. They are comfortable installing them on their own.
        kzzzznot 7y ago
        I expect he’s getting downvoted because he doesn’t offer any reasoning (or substance at all) along with his opinion.
        csomar 7y ago
makecheck 7y ago
I did like being able to distribute an entire app with a download of just a few megabytes, relying on a highly stable system Python (literally worked for 10 years). And these days with smallish SSDs, I find myself desperately freeing up disk space surprisingly often. I’d rather not have every single app be 100+ MB when I know deep down that the things should be tiny.
panpanna 7y ago
In the mean time, ARM publishes educational C code that requires 3 different scripting languages to compile... (Eralier versions of mbed build system needed python, JavaScript and one more)
reid 7y ago
Sounds like these runtimes will still be available via a separate download, similar to how Git and other CLI tools download when you first try to use them. Not a big deal. Makes it easier for folks who want newer versions and avoid any strange behavior with coexisting with the built-in runtimes.
- Traster 7y ago
  Yeah, one of my pet peeves is logging in to a new system and being like "Which version of Python am I going to have to try and avoid invoking today".
  - lapnitnelav 7y ago
    Nothing quite like a bit of snake dodging to start your day.
willyt 7y ago
Most of my Python/Ruby stuff requires additional packages to be installed and so would need to be bundled anyway if I wanted it to be easily transferred to a vanilla machine so I don’t see what the big deal is. I got into programming through wanting to automate something really boring with AppleScript and I got into Ruby (wow that was amazing compared to AppleScript) through wanting to program sketch-up which has a bundled interpreter. When I wanted to use Ruby for other cool stuff, the Ruby website recommended I installed my own so it didn’t mess with the system install. I doubt there are very many people who get into programming by accidentally typing Ruby at the command prompt. Most will come to it via a the getting started page for the language they are interested in or because it’s bundled with the software they use for their job.
k__ 7y ago
They were often outdated anyway, so it's no big loss. Gives other languages a better standing too :)
donatj 7y ago
Not that Apple even supports Widgets anymore beyond their continued vestigial existence, but it was always nice back in the day to have the power to call out from widgets to scripting languages for more power.
alerighi 7y ago
Good thing, python2.7 is deprecated and no longer receives security updates, and a lot of Linux distributions (Arch and Fedora for example) plans to remove it from the main repositories at the end of this year, so having it installed doesn't make sense. Even the perl and ruby version installed is old, and nearly nobody uses perl or ruby at this day. Maybe perl is still used by some programs and scripts, for example TexLive relies on perl, or ruby is used for brew. But you better installing more updated version yourself so removing it is not a big deal. There is no meaning to keep old script interpreters installed, if you want to use them you probably want to install a more modern version, if you don't need them it's better to not have them.
- toyg 7y ago
  > python2.7 is deprecated and no longer receives security updates Let's not go overboard - 2.7 will get security updates and patches until the end of December. > nearly nobody uses perl or ruby at this day. Well, except for homebrew of course, the Ruby-based package manager nearly "everybody" uses...
  - Longhanks 7y ago
    Homebrew (after installation) uses its own, bundled ruby runtime and will finish removing any dependency on system ruby long before Catalina is publicly available. https://twitter.com/MacHomebrew/status/1136249501252038662 https://twitter.com/MacHomebrew/status/1136249501252038662
    - toyg 7y ago
      I know, but this wasn't the case when it started. Besides, I believe the parent's point was that nobody uses ruby or perl for anything anymore, regardless of whether it's preinstalled or not. Which is obviously silly when looking at homebrew's internals.
nickthemagicman 7y ago
brew install python problem solved?
usermac 7y ago
And I have a 4+ year old Perl script I use daily. Yeah, yeah, I know I can install Perl myself but when I distribute it I was expecting it, Perl, to be there—never mind that it is an out-of-date version—I wrote it accordingly.
api 7y ago
I think people are reading more into this than is there. They're just not going to ship their own (outdated) versions of these anymore because they're not needed in the core OS. You can just "brew install" them, which most people who actually use them do anyway because the stock versions are too old.
deleted 7y ago
[deleted]
musicale 7y ago
I guess it is the macOS way for every app to be self-contained and include all of its own libraries. But I miss the idea of shared libraries; not only can they potentially save memory and disk space, but it makes bug fixes easier because you can fix the shared library without having to update every app separately.
kazinator 7y ago
Of course; why would they want to maintain this crud and its dependency hell. If the slightest thing is wrong, this or that application breaks. An application should include the correct version of everything it needs to do its job, period. Only problem is security: with multiple applications including their own dependencies, some of those dependencies will lag behind in their security updates. You can't just get a single fix for your Python run-time and fix it in all applications at once.

435 points by undefined1 7y ago

exabrial 7y ago

I think that's ok, most everyone installs homebrew

sys_64738 7y ago
Including macOS developers!
jeremyjh 7y ago
How do you install homebrew without Ruby?
- AlexeyBrin 7y ago
  You basically rewrite the current Ruby installer in a shell script that will download a Ruby version from Homebrew ...
- exabrial 7y ago
  Pkg file...
  - foobiekr 7y ago
    encoded and embedded in a bash script, more likely.
robin_reala 7y ago
Right, but homebrew is written in Ruby. So there’ll need to be some more bootstrapping stages to install a recent Ruby first. Although it looks like they’ve got a plan: https://twitter.com/machomebrew/status/1136249501252038662?s=21 https://twitter.com/machomebrew/status/1136249501252038662?s...
mixmastamyk 7y ago
They should choose a package manager.
- wahern 7y ago
  It's called the App Store.
  - saghm 7y ago
    You can't install Ruby/Python from the App Store
    - saagarjha 7y ago
      …yet.
      - vortico 7y ago
        and probably ever. It's not the right tool for the job, unless Apple really does some restructuring.
fooblitzky_bias 7y ago
"I think that's ok, most everyone installs homebrew" Most everyone who doesn't know better. Brew is a trainwreck that breaks critical functions in macOS.
- saagarjha 7y ago
  To be fair, Homebrew usually tries to not do this :)

Reedx 7y ago

Seems like a good move. Less cruft and don't have to deal with managing versions between the one you want and the one already on the system.

xmichael999 7y ago
I can't recall using the built-in version in ages, it is pretty much always homebrew before you even start. So I think this is a great move.
- rrix2 7y ago
  How is homebrew installed?
  - grzm 7y ago
    https://brew.sh https://brew.sh
    - aquabeagle 7y ago
      Right... /usr/bin/ruby -e ...
      - Operyl 7y ago
        Oh my god, it's the end of the world, Homebrew will never be able to make another installer that doesn't use ruby ever again! /s But let's be real, they're either going to make a .pkg, or just use a shell script or .. really, there's dozens of ways. They've been using an alternative version of ruby packaged in the homebrew folder for a while now. The only part of the process that requires System Ruby is the installer, now.
      - delinka 7y ago
        https://www.ruby-lang.org/en/documentation/installation/#building-from-source https://www.ruby-lang.org/en/documentation/installation/#bui...

ihuman 7y ago

Does this include AppleScript and the Javascript runtime for AppleScripts? They reference Script Editor in the section above, so I'm assuming they're safe. Also, what's the best way to install homebrew if you don't have a system-level ruby? The current installer is a ruby script. Is it possible to get some sort of ruby-bootstrap that can install homebrew and a homebrewed ruby?

olliej 7y ago
No - the problem with the misc other interpreters is that they don’t provide sufficient binary stability for Apple to simply include the newest one in every update (which I suspect they would happily do). They’re not removing the commandline (although moving to zsh? :-/), or banning interpreters. They’re just not including them built into the os anymore. As for the AppleScript and JavaScript questions: Apple makes the runtimes for those, and makes sure they remaining binary compatible. Take a program that linked to (and used) the javascriptcore api to add js support. Something compiled 10 years ago will run without recompilation. Thats the bar for stability.
- ihuman 7y ago
  I think you read more into my question than what I meant. I was asking literally about the best way to install it was without a system level ruby. Once you have homebrew, you can install ruby; but what about before that? Download and install ruby from ruby-lang.org, install homebrew and a brewed ruby, then uninstall the one from ruby-lang.org?
  - azinman2 7y ago
    I’m guessing home brew will end up creating a packaged installer than includes a home brew upgradable ruby
    - saagarjha 7y ago
      I'd think a script that you pipe into a shell with admin privileges is more likely ;)

DividableMiddle 7y ago

This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.

new_realist 7y ago
Does OSX offer reasonable container technology? chroot?
- wedn3sday 7y ago
  Singularity recently released a (non-fully featured, but still useful) mac version.
- pram 7y ago
  macOS has a native hypervisor framework, Docker and xhyve uses it. https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit https://github.com/moby/hyperkit
  - AceJohnny2 7y ago
    In other words, nothing serious. Does anyone actually use Docker on Mac? Xhyve is more of a proof-of-concept than a production-ready tool.
    - abhorrence 7y ago
      I use Docker on Mac, and know many others who do as well.
    - RussianCow 7y ago
      > Does anyone actually use Docker on Mac? What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.

olliej 7y ago

Probably the right call - many of them don’t have abi or api stability guarantees, or in the case of python needlessly broke backwards compatibility that is still causing pain today. Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work. The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update? People ship out of date libraries because updating requires changes beyond just pulling a new binary requires more work than the gain will give them. It’s part of why companies like Apple and Microsoft care so much about backwards compat: they want people running the most recent OS possible, and they don’t want people to avoid updates. Every time an update breaks something for anyone, they hold off updating in future. On the other side, developers don’t want to invest time and money into a feature that they don’t think will work/cause their app to crash in future.

userbinator 7y ago
It’s part of why companies like Apple and Microsoft care so much about backwards compat Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility. You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're willing to restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too, then it goes back to the early 80s.
- valleyjo 7y ago
  Completely true. Apple only cares about back-compact down to a few older major versions. So often the big projects (like modern apps, Windows 10 S, etc) Microsoft does fail or struggle to gain traction IMO because of the blessing and curse of their back-compat requirements.
  - DaiPlusPlus 7y ago
    Those big-projects you mentioned failed to gain traction in the first place - with a tiny use-count for (e.g.) UWP vs Win32 it’s easy for MS to not take back-compat as seriously.

mutt2016 7y ago

Wait.. So I'll have to install Ruby before I can install Brew? Ok. Ruined 2 minutes of my day.

azinman2 7y ago
Except it’ll be the latest, and then easily updatable after that. Expect package installers that make the whole thing easier and more secure (signed packages vs a curl | /bin/sh)
dwaite 7y ago
I expect homebrew to switch to installing their own local ruby via a zsh. They already install their own local ruby today, but use the system-ruby as an entrypoint.
rgovostes 7y ago
Good point. Hopefully the Homebrew installer script will bootstrap this for you. They already build and distribute binary packages, they probably can easily download the existing Ruby package and execute it.
nicky0 7y ago
You install Brew every day?

AceJohnny2 7y ago

Fucking finally! Between this and deprecating Bash [1], I'm glad macOS is dropping all these obsolete packages it's been including (Emacs soon?). Their antiquity mean they're more of a hindrance to proper development than help. Now, if they'd officially endorse one open-source packaging solution as an alternative, I'd be fully satisfied. [1] https://news.ycombinator.com/item?id=20090193 https://news.ycombinator.com/item?id=20090193

rgovostes 7y ago
MacPorts has or had semi-official status. It was hosted by macOS Forge, which was an official Apple site that included other projects such as XQuartz. I'm unclear on the current status.
- AceJohnny2 7y ago
  MacOS Forge has been deprecated for years (2016?), all its hosted projects have moved off. I don't think Apple has done anything for MacPorts since then, so I wouldn't consider it a current endorsement.
- selectodude 7y ago
  Its a shame MacPorts kind of died on the vine. It just seems so much cleaner and less hacky than Homebrew.
  - AceJohnny2 7y ago
    It's not dead! [1] I use it daily, and it's working just fine. For example, check out the (centralized) list [2] of Ports files that define the packages. You can see it's pretty lively But your perception that it's dead is certainly symptomatic of an issue for the project. [1] yes yes Monty Python [2] https://github.com/macports/macports-ports https://github.com/macports/macports-ports
  - hnarayanan 7y ago
    It’s not dead. I too have used it nearly daily for over 15 years.

thrower123 7y ago

So, what's the point of using Macs as a better Linux, if they are continuing to strip out the parts of Linux that are useful? Might as well use WSL or Cygwin and save a bunch of money.

dwaite 7y ago
This is a great move. It will be two lines of code and two minutes to install the interpreter you need, and you will no longer be tied to a global, possibly ancient system version. Likewise, you won't have your own installed applications break on update because (for example) python2.7 was EoL and dropped from the OS. Installing your own instance of python or ruby should be two lines and about two minutes assuming a decent internet connection.
zapzupnz 7y ago
You do realise that the reason these things are being stripped out is because macOS includes hideously old versions for backwards compatibility with older software that depended on them, right? There is no real loss here; no sane users would use the built-in versions due to their age. It has been preferable to download and install newer versions for a long time, this changes nothing. And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows, then it's surely also no effort at all to install Homebrew or MacPorts (or other) — with the benefit of not working in a contrived, separate environment. This comment betrays a fundamental lack of understanding of modern developer workflows in macOS and feels just slightly like a troll comment from someone who likely doesn't use macOS to begin with.
- wahern 7y ago
  > And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows Well, plenty of people use macOS precisely because it was like a more consistent Linux out-of-the-box. Apple will lose a ton of mindshare; indeed, they are losing a ton of mindshare. They've been slowly deprecating things for years, now, and leaving the rest to rot, and open source developers are increasingly drifting away. About 10 years ago macOS and Apple hardware started becoming the preferred kit for open source developers, and this showed--Apple kit was seen everywhere in Silicon Valley and eventually became the default kit given out by big software companies. That was all because of macOS' Unix personality. That's all going to change over the next several years. I was surprised when WSL 1.0 debuted. By making Linux _native_ on Windows, it solidified Linux' position as the dominate server-side platform. I'm not at all surprised they're ditching it for WSL 2.0, which is just Linux in a VM with a networked filesystem, precisely what people have been doing for about 15 years, keeping it solidly second class--like running Windows on macOS.

ytch 7y ago

I thought it is reasonable. IIRC, my MacOS 10.14.5 has python 2.7.10 built-in (I've install home-brew on it, but I guess it is the Apple built-in version), it is too old (Release Date: May 23, 2015).

NelsonMinar 7y ago

So what about shell scripts?

saagarjha 7y ago
Apple will have to ship with a POSIX compliant shell if they'd like to keep their UNIX® certification.

markstos 7y ago

Interesting that some version of Python will still retain a default status, while Perl and Ruby are both being removed from the default install. Congratulations, Python 3!

briandear 7y ago
That’s because no ruby developer ever depends on system ruby. It superfluous, not a vote for python.

snowoutside 7y ago

With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.

cprayingmantis 7y ago
The down side to that is that ruby is currently required to install Homebrew.
- andoriyu 7y ago
  Just rewrite it in rust.
- drivingmenuts 7y ago
  There will be a .pkg for that, if there isn't already.
  - george_perez 7y ago
    They seem to package a portable ruby already. https://twitter.com/MacHomebrew/status/1136249501252038662 https://twitter.com/MacHomebrew/status/1136249501252038662
- month13 7y ago
  Could also just use bash to bootstrap an environment, like how RVM does.
- dsl 7y ago
  You already need Xcode to get Homebrew working, and that will most likely be the vector by which optional scripting languages will be installed.
  - saagarjha 7y ago

daemonhunter 7y ago

Had to get rid of something to make way for those $1000 monitor stands.

chunsj 7y ago

Oh, please remove them ASAP or include the most recent version of them.

bla3 7y ago

I don't understand why everyone is so excited about this. I don't like using brew. I use a Mac because things just work. It was annoying that the system versions were old, but most of the time they were still workable. To me, this is another (admittedly small) thing I liked about the Mac that's going away.

olliej 7y ago
The problem is accruing security flaws (increasingly difficulty to back port fixes), and also the problems that come up when you install a different version (lots of Software just assumes it can use the same system python, which causes issues when it isn’t the archaic version).
- bla3 7y ago
  I'd prefer if Apple took care of security fixes instead of some third party. And they could ship newer versions if keeping the old ones secure is harder.
  - olliej 7y ago
    The problem is that updating to a new version isn’t possible if it breaks existing software - what happens is that the end user experience is “I installed these updates and Apple broke my program” so don't update in future, and tell others not to as well. The only way to stop the OS from including out of date software and libraries is to not ship them if they don’t have stable abi. That’s what Apple is doing: it can’t reasonably ship them and keep them up to date, so it is going to stop.
    - jdsully 7y ago
      Doesn’t removing them have the same issue? “My software dependent on this ancient python no longer works - because there’s no python anymore”
      - olliej 7y ago

gerbilly 7y ago

It might be nicer if they curated more up to date versions instead, but of course it's easier to remove things than to carefully manage dependencies. I'm not a big fan of brew however. Last time I checked it didn't seem to work well when switching between users.

ken 7y ago

Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid. (As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.") Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them. They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.

drivingmenuts 7y ago
A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system. If I'm not mistaken, current best practice is to somewhat isolate third-party developer software anyway, using homebrew, a VM or other solutions (not sure about Docker - don't use it). I can see where it would be an issue with developing for MacOS or iOS, but third-party web development doesn't really need anything that is installed on the system, and in my experience, it's actually better not to base it on the MacOS default packages.
- Wowfunhappy 7y ago
  Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions. It doesn't use a container or anything like that. Certainly not a full-on VM. Maybe I'm old-fashioned (feels weird to say that as a 25-year-old, but here we are), but I quite like not having everything be in a container all the time.

shereadsthenews 7y ago

Civ IV will never work again. RIP.

Marsymars 7y ago
As a huge fan of Civ IV, I've found the macOS version pretty janky. I have a generally better experience on my Mac by just using Steam In-Home Streaming from my Windows box.
mthoms 7y ago
Why is that?
nottorp 7y ago
It uses the system python? I doubt it.
- shereadsthenews 7y ago
  It absolutely does and macOS has already broken it several times. This I guess to some extent demonstrates the folly of having one. https://forums.civfanatics.com/threads/how-to-get-civ4-bts-working-on-el-capitan-and-sierra.549923/ https://forums.civfanatics.com/threads/how-to-get-civ4-bts-w...

lenkite 7y ago

Ok, this means homebrew needs to be compiled to a native binary!

yellowapple 7y ago
Or a shell script.
deleted 7y ago
[deleted]

Godel_unicode 7y ago

It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". One more piece of evidence that Microsoft cares about developers more than Apple does.

pcr910303 7y ago
Well, python 2.7.5 isn’t ‘modern’ python... AFAIK :-)
- Godel_unicode 7y ago
  Not sure what that version number has to do with anything...? The Microsoft package is 3.7 Edit: 3.7.3, specifically.
grumpydba 7y ago
> It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". You still need admin rights and an internet setup. Linux is still king.
- Sharparam 7y ago
  On what system can you install python without Internet access?
  - grumpydba 7y ago
    On Linux you don't need to install it it is there by default on all major distros.

jzl 7y ago

I'm trying to understand how these two points reconcile. "Future versions of macOS won’t include scripting language runtimes by default" and "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." If Catalina is the last version with any scripting languages at all, why bother with the second point? Or will python3 still be available in the future despite point 1?

jaabe 7y ago
As I understood it, scripting languages will still be available to the user, they just won’t have ancient versions preinstalled. Of course that also means you can’t rely on them being installed at all as a developer. Which means you should start bundling the stuff you need to run your app, and, they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient.
- jzl 7y ago
  Ok, I guess it's worded vaguely enough to allow for the possibility of optional installation ("by default"), even though they don't outright promise that they'll offer a way to install it. (I interpreted it in the same way as "macOS doesn't include Photoshop by default".) Having it come from the app store doesn't seem totally appropriate since it would need to do more than dump a bundle into /Applications, like making some /usr/local/bin symlinks. Maybe they'll allow themselves that exception. "they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient" --> Right, I couldn't figure out if that's all they meant. Valid point or not, it doesn't seem appropriate to make it in the context of those notes. If you're going to make me bundle the language anyway, don't also give me a lecture about which version to use. :)
  - wtallis 7y ago
    I suspect they plan to distribute the scripting languages the same way they currently handle the command line developer tools package, where the OS offers to download and install the package the first time you try to run one of those tools.

zmmmmm 7y ago

How deep you are willing to go with conspiracy theories ... If one was planning to kill off all non-approved software on an OS, what would you do first? Remove all the runtimes that can execute unapproved software of course. Then you are free to impose signing as a requirement for applications and a mandatory app store, and reap the 30% rent tax forever more. Is Apple doing that? Of course, we can't tell. There are lots of good reasons to do this that aren't evil. The best evil plans are indistinguishable from good plans but just happen to have evil outcomes that are in your interest.

saagarjha 7y ago
It is trivial to package a scripting runtime with an App Store application; so trivial, in fact, that a number of apps for iOS do this already.
- zmmmmm 7y ago
  That doesn't really contradict anything above. It still remains true that if they were planning on removing ability to run unapproved applications from OSX, the first step would be to take out the ability to do that which is installed by default. Restricting what App Store applications can do would come later (and be controlled by policy rather than technical limitations).

deleted 7y ago

[deleted]

bayareanative 7y ago

Not a big deal. Anyone doing serious development at scale would mirror production anyways (12factors principle). Plus, who uses Apple's obsolete junk anyhow? For a very long time, homebrew and macports has solved Apple macOS not rolling releasing terminal-based packages. Teapot tempest.

mahgnous 7y ago

Doesn't need to have them included at this point. I'd much rather install them manually.

TimTheTinker 7y ago

I think this is great, but at the same time, auto-installing homebrew ought to be an option (perhaps enabled by default) when installing the “XCode command line tools”. Better yet, offer a “developer setup” app that sets up the command line tools, homebrew, iTerm2, updated bash/zsh, and more. Apple would do best to pave the cow paths developers have already worn into macOS, especially when it comes to command line utilities. A dev setup app would just make it quicker/simpler and pave the way for newbies to get into development.

jarcane 7y ago
Homebrew is not the only package provider for MacOS.
- reikonomusha 7y ago
  Would Apple be in the wrong simply being opinionated about using Homebrew?
  - hasahmed 7y ago
    Yes
    - csomar 7y ago
      I'm not sure why you are getting downvoted. I'd not like it if Apple will opinion-ate and make any package manager a default. Package managers are for software developers. They are comfortable installing them on their own.
      - kzzzznot 7y ago
        I expect he’s getting downvoted because he doesn’t offer any reasoning (or substance at all) along with his opinion.
        csomar 7y ago

makecheck 7y ago

I did like being able to distribute an entire app with a download of just a few megabytes, relying on a highly stable system Python (literally worked for 10 years). And these days with smallish SSDs, I find myself desperately freeing up disk space surprisingly often. I’d rather not have every single app be 100+ MB when I know deep down that the things should be tiny.

panpanna 7y ago

In the mean time, ARM publishes educational C code that requires 3 different scripting languages to compile... (Eralier versions of mbed build system needed python, JavaScript and one more)

reid 7y ago

Sounds like these runtimes will still be available via a separate download, similar to how Git and other CLI tools download when you first try to use them. Not a big deal. Makes it easier for folks who want newer versions and avoid any strange behavior with coexisting with the built-in runtimes.

Traster 7y ago
Yeah, one of my pet peeves is logging in to a new system and being like "Which version of Python am I going to have to try and avoid invoking today".
- lapnitnelav 7y ago
  Nothing quite like a bit of snake dodging to start your day.

willyt 7y ago

Most of my Python/Ruby stuff requires additional packages to be installed and so would need to be bundled anyway if I wanted it to be easily transferred to a vanilla machine so I don’t see what the big deal is. I got into programming through wanting to automate something really boring with AppleScript and I got into Ruby (wow that was amazing compared to AppleScript) through wanting to program sketch-up which has a bundled interpreter. When I wanted to use Ruby for other cool stuff, the Ruby website recommended I installed my own so it didn’t mess with the system install. I doubt there are very many people who get into programming by accidentally typing Ruby at the command prompt. Most will come to it via a the getting started page for the language they are interested in or because it’s bundled with the software they use for their job.

k__ 7y ago

They were often outdated anyway, so it's no big loss. Gives other languages a better standing too :)

donatj 7y ago

Not that Apple even supports Widgets anymore beyond their continued vestigial existence, but it was always nice back in the day to have the power to call out from widgets to scripting languages for more power.

alerighi 7y ago

Good thing, python2.7 is deprecated and no longer receives security updates, and a lot of Linux distributions (Arch and Fedora for example) plans to remove it from the main repositories at the end of this year, so having it installed doesn't make sense. Even the perl and ruby version installed is old, and nearly nobody uses perl or ruby at this day. Maybe perl is still used by some programs and scripts, for example TexLive relies on perl, or ruby is used for brew. But you better installing more updated version yourself so removing it is not a big deal. There is no meaning to keep old script interpreters installed, if you want to use them you probably want to install a more modern version, if you don't need them it's better to not have them.

toyg 7y ago
> python2.7 is deprecated and no longer receives security updates Let's not go overboard - 2.7 will get security updates and patches until the end of December. > nearly nobody uses perl or ruby at this day. Well, except for homebrew of course, the Ruby-based package manager nearly "everybody" uses...
- Longhanks 7y ago
  Homebrew (after installation) uses its own, bundled ruby runtime and will finish removing any dependency on system ruby long before Catalina is publicly available. https://twitter.com/MacHomebrew/status/1136249501252038662 https://twitter.com/MacHomebrew/status/1136249501252038662
  - toyg 7y ago
    I know, but this wasn't the case when it started. Besides, I believe the parent's point was that nobody uses ruby or perl for anything anymore, regardless of whether it's preinstalled or not. Which is obviously silly when looking at homebrew's internals.

nickthemagicman 7y ago

brew install python problem solved?

usermac 7y ago

And I have a 4+ year old Perl script I use daily. Yeah, yeah, I know I can install Perl myself but when I distribute it I was expecting it, Perl, to be there—never mind that it is an out-of-date version—I wrote it accordingly.

api 7y ago

I think people are reading more into this than is there. They're just not going to ship their own (outdated) versions of these anymore because they're not needed in the core OS. You can just "brew install" them, which most people who actually use them do anyway because the stock versions are too old.

deleted 7y ago

[deleted]

musicale 7y ago

I guess it is the macOS way for every app to be self-contained and include all of its own libraries. But I miss the idea of shared libraries; not only can they potentially save memory and disk space, but it makes bug fixes easier because you can fix the shared library without having to update every app separately.

kazinator 7y ago

Of course; why would they want to maintain this crud and its dependency hell. If the slightest thing is wrong, this or that application breaks. An application should include the correct version of everything it needs to do its job, period. Only problem is security: with multiple applications including their own dependencies, some of those dependencies will lag behind in their security updates. You can't just get a single fix for your Python run-time and fix it in all applications at once.