14 ms·

Xcode 11 Release Notes (https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes https://developer.apple.com/documentation/xcode-rel

Xcode 11 Release Notes (https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes https://developer.apple.com/documentation/xcode-release-note...) "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)" Found via https://mjtsai.com/blog/2019/06/04/scripting-languages-to-be-removed/ https://mjtsai.com/blog/2019/06/04/scripting-languages-to-be...

darrenf 5y ago
Regarding Perl, rather than removing it Apple actually upgraded it – from 5.28 to 5.30 – in Big Sur 11.3. I wasn't the only one briefly surprised and bitten by it: • https://github.com/Homebrew/brew/issues/10127#issuecomment-828121139 https://github.com/Homebrew/brew/issues/10127#issuecomment-8... • https://github.com/Homebrew/brew/issues/11275 https://github.com/Homebrew/brew/issues/11275
- kqr 5y ago
  I doubt they'll be able to get rid of Perl any time soon. However, how come things break when Perl is upgraded? From what I've heard, Perl should be extremely backwards compatible. What am I missing?
  - darrenf 5y ago
    For me, I had been too lazy to use Homebrew or Perlbrew since I don't develop locally per se, but I wanted `Perl::LanguageServer` for use with VS Code – which I'd installed via `local::lib` into `~/perl5/`. Post-upgrade either various modules weren't found (because they were installed in a versioned path), or they didn't compile because the XS components had been compiled against the prior version of Perl.
    - mst 5y ago
      Right, that's a risk you take doing local::lib against system perl. I will often use the system perl to bootstrap https://p3rl.org/Perl::Build https://p3rl.org/Perl::Build which makes building -one- perl for local use easier than perlbrew/etc. - and then https://p3rl.org/App::plx https://p3rl.org/App::plx for managing per project environments if I need that
  - pjmlp 5y ago
    Enjoy the incompatible changes section from all Perl history, https://perldoc.perl.org/perl#History https://perldoc.perl.org/perl#History
    - anthk 5y ago
      That's bullshit. I've run exercises from the Orelly CD bookshelf more than a decade old and they just run as is.
      - pjmlp 5y ago
        That just proves the point you got lucky with what language features were used on the exercises.
      - viraptor 5y ago
        Almost all exercises are minimal in nature. They will touch only small areas and (unless the book is based around advanced ideas) will not touch tricky / changing functionality. So I'm not surprised exercises still work.
      - Ensorceled 5y ago
        > That's bullshit. Dude, there is literally a link with references.
    - mst 5y ago
      That's a link to complete changelogs. Those aren't an "incompatible changes seection". perldelta covers bugfixes, feature additions etc.
      - pjmlp 5y ago
        foreach entry in "https://perldoc.perl.org/perl#History" do open entry on browser search for "Incompatible Changes" section read section contents Writing a script in Perl to do the above is left as exercise to the reader. Hint, use LWP.
  - rurban 5y ago
    They had to recompile their perl XS bindings, where esp. subversion is horrible to update.
- Stranger43 5y ago
  Perl is requires for apple to maintain their unix(tm) certification. And while they likely dont see it as core to what they want macos to become it would be an news story in the more sensationalist part of the IT press if they were to drop it. and big sur is still listed as certified https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/.
  - tpush 5y ago
    Genuine question: is there anyone (corporate or not) that cares that macOS is a certified Unix?
    - tgragnato 5y ago
      Many care that macOS is Unix-like, I doubt anyone cares about the certification.
    - mekster 5y ago
      It's still impressive that powerful command line environment and the best GUI are offered in a same OS. Usually it's one or the other.
      - hnlmorg 5y ago
        That's a hugely subjective comment and there are plenty of instances throughout history of a powerful CLI and sophisticated GUI being included as part of the same OS (Xerox Alto, BeOS, NeXT, Plan 9). Linux and *BSD's have plenty of popular WM / DEs too: personally I'd rate KDE above anything commercial I've used but that's my subjective preference. Heck these days even Windows can be argued as having a "powerful CLI" with both WSL and Powershell existing, and the Windows UI has it's fair share of fans (regardless of what our own personal preferences might be).
      - pornel 5y ago
        It used to be, but Apple seems to have lost interest in the Unix/Open Source side of macOS a decade ago. They've abandoned GNU tools after GPLv3 (2007), haven't added anything new, and just let the old stuff limp along until it's obsolete. Nowadays macOS needs something like Homebrew to fill the gaps. It's still slightly better than Windows + WSL, but Microsoft is catching up, while Apple seems to think that iPadOS is the future.
- mrpippy 5y ago
  Yes, but Perl still has a warning banner when you run it (at least in Big Sur and Monterey): % perl -de1 WARNING: This version of perl is included in macOS for compatibility with legacy software. In future versions of macOS the perl runtime will not be available by default, and may require you to install an additional package.
jcfields 5y ago
They've actually been warning users since Catalina (if not longer) when the following are run: python irb php --version tclsh For PHP, it also shows up in Apache's server string: Apache/2.4.46 (Unix) PHP/7.3.24-(to be removed in future macOS) mod_perl/2.0.9 Perl/v5.30.2 on hostname Personally, I've been hoping they'd do this for a while since it's annoying having two versions of each interpreter installed (the system one that can't be updated and the one I installed myself via Mac Ports). Anyone who uses these languages much probably already has a package manager installed. I think they should leave Perl, though, since it's as much as Unix system utility like awk or sed as a programming language.
- rbanffy 5y ago
  I find the MacPorts approach to be very developer friendly and I wouldn’t really want to use a “naked” macOS install as my work machine. MacPorts makes it look like a very credible BSD workstation. I really have no issue with Apple trimming down the surface of the OS to a minimum.
- mrsuprawsm 5y ago
  While the warning shows for python2, it doesn't show for python3, implying that it's here to stay for now: % /usr/bin/python WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal. Python 2.7.16 (default, Mar 25 2021, 03:11:28) [GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin Type "help", "copyright", "credits" or "license" for more information. >>> % /usr/bin/python3 Python 3.8.2 (default, Dec 21 2020, 15:06:04) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>
  - deleted 5y ago
    [deleted]
  - _wldu 5y ago
    Python is to Unix/Linux/Mac what PowerShell is to Windows. It's here to stay.
enriquto 5y ago
> for compatibility with legacy software. The way it is written, it sounds like they are trying to hide the fact that said "legacy software" is part of the (new) system itself. Otherwise they wouldn't need to include it in the base install. > Python, Ruby, and Perl The order they use for the languages hides the fact that, at least for Catalina, Perl is by far the most used scripting language by core elements of macOS, even more than the shell. Check it by yourselves: file -b /{usr/,}{s,}bin/* |cut -d\ -f1,2|sort|uniq -c|sort -n|tail 13 setuid Mach-O 23 a /usr/sbin/dtrace 50 a /usr/bin/perl5.28 53 a /usr/bin/perl5.18 81 POSIX shell 116 Perl script 954 Mach-O 64-bit Conclusion: Apple is a Perl shop.
- Cthulhu_ 5y ago
  What they could do is use an internal, non-user-usable runtime for their own perl scripts and allow the user to install their own one. And of course compile their scripts into executables or something.
unethical_ban 5y ago
That is actually truly unfortunate, I think. While I understand the issues with lagging versions of system-installed languages, I think there is a comfort and educational value in having them available as part of the system for anyone to access without having to go fetch it. It "lowers the friction of curiosity". (And, it allowed our shadow IT custom request system and automation package to be built in 2014. I hope RHEL never takes this away).
- Rebelgecko 5y ago
  I'm inclined to agree with you. When teaching someone programming, there's something comforting about telling them they can just open up a command prompt and type "python" (or irb, perl, etc) and start programming. I recently wrote a short Ruby program to help my not-computer-literate-at-all mother automate a task that would've taken hours and hours to do manually. She's barely comfortable using GUI programs, but because Ruby was already installed and I was able to give her clear directions she was able to run the program in Terminal.app without much trouble. It would've been frustrating as hell to remotely get her set up with homebrew (or whatever the new hotness is in package managers nowawadays), install the right version of Ruby, fix any $PATH shenanigans, etc. (There was still some trickiness because her included version of Ruby was super old and couldn't install gems because it used an old version of SSL/TLS, but we were able to figure out a workaround)
h1fra 5y ago
That's good, too many package assume you have python installed in macos and go looking into the wrong folder. Or default python2 breaking stuff that assume you have a recent install
aasasd 5y ago
Bummer about Perl, because a stint with a slower machine taught me just how slow Python is. My Lua scripts were often done faster than Python starts up—even though the scripts were doing file i/o. So, for anything like personal productivity scripting, Python is bad. However Lua requires managing the runtime and modules—and I was thinking about dusting off Perl, since it's pretty fast and is just always around like Sh while not being garbage at data structures and code organization.
nickysielicki 5y ago
Does this mean MacOS is finally going to get a real package manager?

darrenf 5y ago

Regarding Perl, rather than removing it Apple actually upgraded it – from 5.28 to 5.30 – in Big Sur 11.3. I wasn't the only one briefly surprised and bitten by it: • https://github.com/Homebrew/brew/issues/10127#issuecomment-828121139 https://github.com/Homebrew/brew/issues/10127#issuecomment-8... • https://github.com/Homebrew/brew/issues/11275 https://github.com/Homebrew/brew/issues/11275

kqr 5y ago
I doubt they'll be able to get rid of Perl any time soon. However, how come things break when Perl is upgraded? From what I've heard, Perl should be extremely backwards compatible. What am I missing?
- darrenf 5y ago
  For me, I had been too lazy to use Homebrew or Perlbrew since I don't develop locally per se, but I wanted `Perl::LanguageServer` for use with VS Code – which I'd installed via `local::lib` into `~/perl5/`. Post-upgrade either various modules weren't found (because they were installed in a versioned path), or they didn't compile because the XS components had been compiled against the prior version of Perl.
  - mst 5y ago
    Right, that's a risk you take doing local::lib against system perl. I will often use the system perl to bootstrap https://p3rl.org/Perl::Build https://p3rl.org/Perl::Build which makes building -one- perl for local use easier than perlbrew/etc. - and then https://p3rl.org/App::plx https://p3rl.org/App::plx for managing per project environments if I need that
- pjmlp 5y ago
  Enjoy the incompatible changes section from all Perl history, https://perldoc.perl.org/perl#History https://perldoc.perl.org/perl#History
  - anthk 5y ago
    That's bullshit. I've run exercises from the Orelly CD bookshelf more than a decade old and they just run as is.
    - pjmlp 5y ago
      That just proves the point you got lucky with what language features were used on the exercises.
    - viraptor 5y ago
      Almost all exercises are minimal in nature. They will touch only small areas and (unless the book is based around advanced ideas) will not touch tricky / changing functionality. So I'm not surprised exercises still work.
    - Ensorceled 5y ago
      > That's bullshit. Dude, there is literally a link with references.
  - mst 5y ago
    That's a link to complete changelogs. Those aren't an "incompatible changes seection". perldelta covers bugfixes, feature additions etc.
    - pjmlp 5y ago
      foreach entry in "https://perldoc.perl.org/perl#History" do open entry on browser search for "Incompatible Changes" section read section contents Writing a script in Perl to do the above is left as exercise to the reader. Hint, use LWP.
- rurban 5y ago
  They had to recompile their perl XS bindings, where esp. subversion is horrible to update.
Stranger43 5y ago
Perl is requires for apple to maintain their unix(tm) certification. And while they likely dont see it as core to what they want macos to become it would be an news story in the more sensationalist part of the IT press if they were to drop it. and big sur is still listed as certified https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/.
- tpush 5y ago
  Genuine question: is there anyone (corporate or not) that cares that macOS is a certified Unix?
  - tgragnato 5y ago
    Many care that macOS is Unix-like, I doubt anyone cares about the certification.
  - mekster 5y ago
    It's still impressive that powerful command line environment and the best GUI are offered in a same OS. Usually it's one or the other.
    - hnlmorg 5y ago
      That's a hugely subjective comment and there are plenty of instances throughout history of a powerful CLI and sophisticated GUI being included as part of the same OS (Xerox Alto, BeOS, NeXT, Plan 9). Linux and *BSD's have plenty of popular WM / DEs too: personally I'd rate KDE above anything commercial I've used but that's my subjective preference. Heck these days even Windows can be argued as having a "powerful CLI" with both WSL and Powershell existing, and the Windows UI has it's fair share of fans (regardless of what our own personal preferences might be).
    - pornel 5y ago
      It used to be, but Apple seems to have lost interest in the Unix/Open Source side of macOS a decade ago. They've abandoned GNU tools after GPLv3 (2007), haven't added anything new, and just let the old stuff limp along until it's obsolete. Nowadays macOS needs something like Homebrew to fill the gaps. It's still slightly better than Windows + WSL, but Microsoft is catching up, while Apple seems to think that iPadOS is the future.
mrpippy 5y ago
Yes, but Perl still has a warning banner when you run it (at least in Big Sur and Monterey): % perl -de1 WARNING: This version of perl is included in macOS for compatibility with legacy software. In future versions of macOS the perl runtime will not be available by default, and may require you to install an additional package.

jcfields 5y ago

They've actually been warning users since Catalina (if not longer) when the following are run: python irb php --version tclsh For PHP, it also shows up in Apache's server string: Apache/2.4.46 (Unix) PHP/7.3.24-(to be removed in future macOS) mod_perl/2.0.9 Perl/v5.30.2 on hostname Personally, I've been hoping they'd do this for a while since it's annoying having two versions of each interpreter installed (the system one that can't be updated and the one I installed myself via Mac Ports). Anyone who uses these languages much probably already has a package manager installed. I think they should leave Perl, though, since it's as much as Unix system utility like awk or sed as a programming language.

rbanffy 5y ago
I find the MacPorts approach to be very developer friendly and I wouldn’t really want to use a “naked” macOS install as my work machine. MacPorts makes it look like a very credible BSD workstation. I really have no issue with Apple trimming down the surface of the OS to a minimum.
mrsuprawsm 5y ago
While the warning shows for python2, it doesn't show for python3, implying that it's here to stay for now: % /usr/bin/python WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal. Python 2.7.16 (default, Mar 25 2021, 03:11:28) [GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin Type "help", "copyright", "credits" or "license" for more information. >>> % /usr/bin/python3 Python 3.8.2 (default, Dec 21 2020, 15:06:04) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>
- deleted 5y ago
  [deleted]
- _wldu 5y ago
  Python is to Unix/Linux/Mac what PowerShell is to Windows. It's here to stay.

enriquto 5y ago

> for compatibility with legacy software. The way it is written, it sounds like they are trying to hide the fact that said "legacy software" is part of the (new) system itself. Otherwise they wouldn't need to include it in the base install. > Python, Ruby, and Perl The order they use for the languages hides the fact that, at least for Catalina, Perl is by far the most used scripting language by core elements of macOS, even more than the shell. Check it by yourselves: file -b /{usr/,}{s,}bin/* |cut -d\ -f1,2|sort|uniq -c|sort -n|tail 13 setuid Mach-O 23 a /usr/sbin/dtrace 50 a /usr/bin/perl5.28 53 a /usr/bin/perl5.18 81 POSIX shell 116 Perl script 954 Mach-O 64-bit Conclusion: Apple is a Perl shop.

Cthulhu_ 5y ago
What they could do is use an internal, non-user-usable runtime for their own perl scripts and allow the user to install their own one. And of course compile their scripts into executables or something.

unethical_ban 5y ago

That is actually truly unfortunate, I think. While I understand the issues with lagging versions of system-installed languages, I think there is a comfort and educational value in having them available as part of the system for anyone to access without having to go fetch it. It "lowers the friction of curiosity". (And, it allowed our shadow IT custom request system and automation package to be built in 2014. I hope RHEL never takes this away).

Rebelgecko 5y ago
I'm inclined to agree with you. When teaching someone programming, there's something comforting about telling them they can just open up a command prompt and type "python" (or irb, perl, etc) and start programming. I recently wrote a short Ruby program to help my not-computer-literate-at-all mother automate a task that would've taken hours and hours to do manually. She's barely comfortable using GUI programs, but because Ruby was already installed and I was able to give her clear directions she was able to run the program in Terminal.app without much trouble. It would've been frustrating as hell to remotely get her set up with homebrew (or whatever the new hotness is in package managers nowawadays), install the right version of Ruby, fix any $PATH shenanigans, etc. (There was still some trickiness because her included version of Ruby was super old and couldn't install gems because it used an old version of SSL/TLS, but we were able to figure out a workaround)

h1fra 5y ago

That's good, too many package assume you have python installed in macos and go looking into the wrong folder. Or default python2 breaking stuff that assume you have a recent install

aasasd 5y ago

Bummer about Perl, because a stint with a slower machine taught me just how slow Python is. My Lua scripts were often done faster than Python starts up—even though the scripts were doing file i/o. So, for anything like personal productivity scripting, Python is bad. However Lua requires managing the runtime and modules—and I was thinking about dusting off Perl, since it's pretty fast and is just always around like Sh while not being garbage at data structures and code organization.

nickysielicki 5y ago

Does this mean MacOS is finally going to get a real package manager?