Re:macOS deprecating scripting language runtimes, including ...
by Wowfunhappy on Wednesday June 05, 2019 @10:47PM
(#20111160)
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.
Re:macOS deprecating scripting language runtimes, including ...
by saagarjha on Thursday June 06, 2019 @12:51AM
(#20111685)
> Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions
Correction: Homebrew usually installs its binaries in a way that doesn't interfere with the ones provided with the system. It will occasionally override or shadow them and things will break.
Re:macOS deprecating scripting language runtimes, including ...
by toyg on Thursday June 06, 2019 @07:49AM
(#20113569)
> It will occasionally override or shadow them
That's extremely rare, these days. When a conflict is possible, they just drop the new version in the cellar and tell you what to do if you really want to risk shooting yourself in the foot.
Re:macOS deprecating scripting language runtimes, including ...
by zerkten on Wednesday June 05, 2019 @11:40PM
(#20111367)
> 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.
Just like WSL 2.0 (https://devblogs.microsoft.com/commandline/announcing-wsl-2/)?
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.