For end users, the interpreter can be bundled with the application, that is much more stable for everyone.
As long as it's trivial to install after purchase, the removal of this sort of thing is in no way concerning to me. When I've written things natively on my Mac, I've almost ALWAYS had to go get an updated version of perl / python / ruby / whatever to get current.
I currently have over 5 different python versions installed to be able to test against them. The different software I work gets deployed to different environments and I have all those versions installed locally to test.
For end users, it doesn't matter as long as it works. The less moving pieces, the better. A bundled interpreter in the OS gives a stable platform to develop against.
The interpreter can be bundled with the application, of course. But now you have n different interpreters with their own php.ini files and their own set of things to change. Upgrading the application means overwriting those files and causing more pain when they have to figure out why something stopped working.
That's absurd. Five versions of the same language. Each with their own package folders. That's at least 15 GB.
This is a luxury and consequence of infinite compute resources.
How come?
It's pretty practical. I'm a developer. I deploy to multiple targets so I have them all. I test against them. Simple enough.
To talk to the point of the link here, what I distribute to MacOS I only have to worry about 1 interpreter because it's the one embedded on the OS (and at work, I can guarantee the version). The problem for me is Linux and whatever is bundled on the version of the distro that's currently running.
> This is a luxury and consequence of infinite compute resources.
It's a consequence of what I deploy to. If I only had 1 target and could guarantee it, I'd only need one.
I'm not dissing version releases, just the adoption and deprecation. I wrote DirectX drivers for years, and going from DX3 to 5 to 7 meant backwards compatibility, and it was a PITA, but releases came out every two years and were deprecated shortly after so we didn't have vast quantities of exponential regressions. OpenGL was rock solid by comparison. The former was trial-and-error by MSoft, the latter was well thought out by consortium.
Is the strict requirement of a single Python version really that much better?
Regarding deprecating and moving away from Python 2, this has been discussed ad nauseam and the issues have been recognized around it. By the way, this wasn't a language issue, but an issue managing it.
Having said that, do you have any opinions or anything to discuss around the current plans?
Tell that to users of OpenSSL for the past two decades. Have fun when your dependencies use a different version. And yes, 0.9.7e is not compatible with 0.9.7g because semantic versioning be damned.
And how many versions of .Net Express are there installed on computers?
.
I'm a developer, not a user.
I develop for multiple platforms and targets. Not just one OS and implementation. That's why I, as a developer, need many. A user doesn't.
I'm okay with API's breaking and think that it's good and that's why things get versioned out.
But it wouldn't be stable. Or it would be, but it would be hopelessly out of date.
Apple can either keep the bundled interpreters on the same version forever, or they can update it with the OS. Do the former, and it becomes hopelessly out of date. Do the latter, and software updates randomly break stuff.
Either the language developers need to actually keep their languages stable, or everyone else just needs to get used to keeping multiple versions around.
I think you need to define "out of date".
Out of date for me means not receiving security updates and stale. I think you mean not the latest version and stable for me is better in a production environment.
Google example, look at Debian stable.
Well, look at this way—the latest consumer version of macOS still comes with Python 2.
$ /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, Dec 21 2020, 23:00:36)
[GCC Apple LLVM 12.0.0 (clang-1200.0.30.4) [+internal-os, ptrauth-isa=sign+stri on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
$ /usr/bin/python3
Python 3.8.2 (default, Apr 8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
> 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.
How do you stop the latter from becoming the former? When do you make the switch?
And remember, `/usr/bin/python3` wouldn't exist on your system (as more than a stub) if you hadn't installed the developer tools.
I can understand what you wish for. But what you wish for is very far from what we’ve had so far. Time to accept reality.
good luck with that
Brew upgrade takes less than ten minutes or so for me. Things that influence this will be the amount and size of your installed packages and whether they have prebuilt binaries ("bottles") or if you need to build them from source. The latter is on your package maintainers.
I use brew primarily only for packages that are only available on brew. I’m moving to nixpkgs for my packaging needs as soon as the M1 support drops.
/usr/bin/php --version
WARNING: PHP is not recommended
PHP is included in macOS for compatibility with legacy software.
Future versions of macOS will not include PHP.
PHP 7.3.24-(to be removed in future macOS) (cli) (built: Dec 21 2020 21:33:25) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
I'm still using 7.x due to limitations.
This seems like a net positive change to me and I hope they can keep dropping these built in languages.
Wondering if it was really an issue with 2 interpreters or more of an issue with how the system works. More specifically PATH variables, shebangs and prioritizing your custom one over the system one.