8 ms·

What? In a point release? We all knew this was coming, but doing it in a point release seems like exceedingly bad form, particularly as Apple does major releas

What? In a point release? We all knew this was coming, but doing it in a point release seems like exceedingly bad form, particularly as Apple does major releases annually. I never expect point releases to break stuff, at least not on purpose.

empthought 5y ago
The risk of unpatched vulnerabilities between now and the next "major release" far exceeds the risk of inconveniencing anyone foolish enough to rely on the system Python 2.7 installation.
- necovek 5y ago
  What server-oriented GNU/Linux distributions do is to keep patching those vulnerabilities themselves. If they need to do it for a year, it's not that hard.
  - nicce 5y ago
    But is it worth it actually? I doubt that this MacOS version is used on servers…
    - mattl 5y ago
      Define server. Public webserver? Unlikely for sure. Office fileserver? Absolutely. Build server? Sure.
      - nicce 5y ago
        If we go to that road, how often you need Python 2 for fileserver or build server? Now, what is the percentage of that among all MacBooks on latest MacOS out there.
        reaperducer 5y ago
        If we go to that road, how often you need Python 2 for fileserver or build server? Monthly, for me. Or more often if, like last week, a new customer required it.
        Wowfunhappy 5y ago
        I think this mindset is dangerous. There's a really long tail of niche things people do on their computers, such that I suspect a majority of users have at least one niche need. Especially today, when Chromebooks and iPads are available for anyone who only needs basic web browsing. If you stop paying attention to the niches, they add up to a lot of people.
        nicce 5y ago
        You are right, but I would say that this is quite extreme case. This is a programming language which support ended 2 years ago. Only reason to use it is to avoid turning old code base to new one. There are some serious questions if that is really a good approach. And if it is, why you need to use pre-installed Python 2 instead of installing it by yourself?
        Wowfunhappy 5y ago
        I expect that there are users, who are not themselves developers, who are using either apps or scripts which rely on the system-installed Python 2. They likely aren't aware that they're using Python, and they may not even know what Python is. It could be one line in one shell script block in one automator action that a coworker put together five years ago. It's okay for that stuff to break. (I wish Apple would put more effort than they do into making it break less often, but that's neither here nor there.) But, it should break in a major release, when the user is prepared for things to break. It should not break in an update that was installed automatically overnight.
  - deleted 5y ago
    [deleted]
- throw0101a 5y ago
  > The risk of unpatched vulnerabilities If a company as 'small' as (pre-IBM) Red Hat can afford to support Python 2.7, then so can Apple: * https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8-3 https://developers.redhat.com/blog/2018/11/14/python-in-rhel... * https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511 Further, if Debian has the resources to support Python 2.x, then so does multi-trillion dollar company of Apple: * https://packages.debian.org/search?keywords=python2 https://packages.debian.org/search?keywords=python2 If they wanted to announce at the June 2022 WWDC that macOS 13 wasn't going to have it, that's fine. But we're several months into macOS 12.x and such a large change is bad form.
  - Redoubts 5y ago
    Maybe they can afford it, but why should they?
    - simlevesque 5y ago
      To offer a good service. To avoid breaking something the users depend on.
      - danaris 5y ago
        That's what Windows is for.
      - samtheDamned 5y ago
        Apple isn't in the business of spending excess money to avoid breaking things. If anything apple is the opposite.
      - Kalium 5y ago
        Apple supported Python 2 for two years after it was officially sunset by the Python Foundation. They've been advising that they will drop support for longer. How long is long enough to avoid breaking something the users depend on? One more year? Five years? Fifty? I think we can all agree that it's reasonable to drop support at some point, making it just a question of when and at what cost.
- omnicognate 5y ago
  Python 2 EOL was 2 years ago. 20 months before Monterey was released. Edit: And it hardly came out of the blue. Python 2.7 was 10 years old then and people had known they needed to get off it for years.
- superkuh 5y ago
  It's funny how people think old, robust software is suddenly going to spring a bunch of vulnerabilities while sitting there, static, unchanging. It's far more likely the bleeding edge python(s) are going to be getting new bugs. Old software isn't inherently more risky.
  - WJW 5y ago
    Of course it's not going to get new vulnerabilities, but that doesn't mean hackers won't find previously unknown vulnerabilities that have always been there. Looking through the CVE database, core python alone has had 15 CVE reports in 2020 and 2021, and for old pythons those will never be patched. I'll never understand why people think they can write some software and it'll stay pristine forever. Even if it was had no known bugs at some point in the past, the world is a harsh place and your program, its dependencies, its programming language or even its OS can be found to be subtly broken at any moment. Even if it is not outright buggy, the world will change around you until the interfaces you depend on are no longer there. (looking at you, software program at $WORK that only works with PS/2 keyboards but not USB keyboards)
    - loeg 5y ago
      Many of those CVEs will not impact your application code, though. This is just a side effect of Python having a huge and somewhat crusty standard library.
    - Someone 5y ago
      If it is dynamically linked (probably the case, as that’s the norm on Mac OS), it might even get new vulnerabilities. The combination (old Python, new shared library) could have vulnerabilities that neither (old python, old shared library) nor (new python, new shared library) has.
    - lanstin 5y ago
      In the old days, software was like math - it had immutable, provable qualities. In the last several decades software has gradually become more and more like biology, where the core mechanisms are shrouded in mystery and we rely on observation and experiments to understand. The Star Trek game in Basic I typed into a computer is eternally true, a platonic form in a way software now no longer even aspires to be.
- loeg 5y ago
  I've previously worked at a vendor using Python2. Someone brought up this concern. I looked up the number of security releases we had cut in the past due to Python2 vulnerabilities -- it was zero.
  - ShamelessC 5y ago
    This is the reason they are referred to as 0-day exploits and believe me, given enough time they will begin to appear.
    - loeg 5y ago
      Maybe? The timeline here is over a decade. It’s hard to imagine RCE without network facing services.
    - kortilla 5y ago
      We’re talking about a Python interpreter here. It already executes arbitrary input with the ability to write to files and make network connections. What type of vulnerability with it just sitting there as an executable do you expect?
      - ShamelessC 5y ago
        Doesn't need to be an RCE to be considered an exploit of the user's intentions. I can't fathom how people are still trying to use an EOL language or why they would even want to. Learn some new syntax, you'll live and the writing has been on the wall for like 20 years.
        Wowfunhappy 5y ago
        I don't think a whole lot of people are writing new software in Python 2, but I think a lot of people are still running old software via Python 2. Software they didn't write themselves and wouldn't know how to modify. And that's not to say those users won't have to find something new eventually (or migrate the software to a contained environment). It just shouldn't happen in an automatically installed update.
- nonethewiser 5y ago
  >The risk of unpatched vulnerabilities between now and the next "major release" His point doesn't necessitate waiting. You could just classify it as a major release instead. That is not to say it should be a major release necessarily.
  - Wowfunhappy 5y ago
    Right, Apple could have removed Python 2 last fall with the release of Monterrey, and I would have been neither surprised nor unhappy. I was actually kind of surprised when it was still in Big Sur.
    - diebeforei485 5y ago
      > I was actually kind of surprised when it was still in Big Sur. Removing support in the middle of 2020 would have been very unpopular.
      - Wowfunhappy 5y ago
        Then they could have done it in 2021 with the release of Monterrey. Heck, Monterrey was released before Omicron, so if we're concerned about COVID that should have been less disruptive than doing it now.
        diebeforei485 5y ago
        This wouldn't have worked either. Lots of countries, where vaccines weren't widely available yet, were going through a huge Delta wave before and after WWDC. Now that most places have vaccines, it probably doesn't make sense to wait for the next major release because this has already been long delayed. Other factors could have also been at play - perhaps Apple Inc had a lot of internal tools on 2.X and has only recently gotten around to migrating all of those.
- reaperducer 5y ago
  The risk of unpatched vulnerabilities between now and the next "major release" far exceeds the risk of inconveniencing anyone foolish enough to rely on the system Python 2.7 installation. You make an assumption that the way your system and method of working is the same as everyone else on the planet. It is not. I have two tools that I use monthly which require python 2.7. The people who made the tools never updated them to work with 3. For this reason, I have a work box that I cannot upgrade. I know that Macs are aimed at end users, and not developers, but it really is getting harder and harder for me to use my Macs for the kind of work I do. Each major software update borks my virtual hosts. PHP has been removed, and because of code signing requirements, adding it back is so complicated it takes an entire day and filtering through a dozen half-baked online tutorials. No, the ones that say "Just use brew!" are not the answer unless you have a very simple job. I don't use Docker, but from what I read on HN, that's six miles of bad road, too. But as I understand the situation, that's Docker's fault, not Apple's.
  - NavinF 5y ago
    The doctor says to the patient, "What seems to be the trouble?" The patient says, "It hurts when I do this." The doctor says, "Don't do that."
- makecheck 5y ago
  As a counter-point, my app was able to rely on the system Python 2.7 for FIFTEEN YEARS because it was an extremely stable component of the OS (and it allowed the app binary to be literally 10 megabytes). Now? I honestly can’t think of a way to release without adding something like 100-200 MB to the app bundle, consisting of an entire Python installation. With a user-facing app it is not ideal to try to say something like “just download Python and tell me where it is”.
throw0101a 5y ago
> What? In a point release? See also the breaking change of 12.3 kernel extensions with Dropbox and Microsoft OneDrive: * https://www.macrumors.com/2022/01/25/macos-12-3-cloud-storage-changes/ https://www.macrumors.com/2022/01/25/macos-12-3-cloud-storag... * https://help.dropbox.com/installs-integrations/desktop/macos-12-monterey-support https://help.dropbox.com/installs-integrations/desktop/macos...
tombert 5y ago
There's no law saying you cannot install an old version of Python 2.7 manually is there? I assumed this was just removing it from being bundled.
- lanstin 5y ago
  Yeah, and it’s been years or decades since you wanted to use the bundled software on MacOS for stuff that was important. Them removing Python 2 probably will fix more problems due to multiple Python installs than it will break anything. I tend to get a lot of support questions on “how to make this Python thing work on my Mac laptop” and I have seen some screwed up things.
- rovr138 5y ago
  Of course. Brew, docker, no idea if they have working release on the site, but that’s another possible way.
my123 5y ago
As far as I know: Apple OS naming isn't semver. They really have two OS major releases a year, Spring and Fall trains.
floydnoel 5y ago
macOS doesn’t follow SemVer. Major OS releases are often point versions.
easton 5y ago
It’s not semver, but I’m willing to bet (although I haven’t checked) that there were probably a few leftover system apps that didn’t get moved to Python 3 before 12.0 (many of the features were delayed, I’m guessing due to the pandemic their work schedule has been disrupted since Big Sur was feature frozen).
- Wowfunhappy 5y ago
  But see, if that is the case... Apple is a large company with lots of resources and knowledge of their internal roadmap. If it took Apple's own internal developers until now to remove their dependence on Python, then third-party developers and their users should get at least until next fall anyway. (I'm not defending the use of Python 2. I'm arguing that, as a general rule, if something takes the vendor X time, users should be given X + Y time.)
saagarjha 5y ago
It’s a mid-year release for Apple, even if marketing doesn’t indicate it in the version number.
xoa 5y ago
Sibling post mentions the kext breakage happening as well as another example, but I feel like they've been slipping on this as they've had increasing difficulty matching major features to their unbending yearly release schedule. So more and more (and this is the case with macOS 12 also, see Universal Control) we've seen big headline features announced at WWDC keynotes not manage to make it into the .0, but rather trickle in over the .1 to .3 releases. Once that rubicon was crossed having more other major/breaking changes start sliding into point releases doesn't seem too surprising I guess, even if the cultural slippage is irritating. Apple probably has to either give up strict semantic versioning for breaking changes, give up their strict release schedule, or be willing to defer announced features that don't make one major version all the way to the next. Something needs to give. Looks like they've decided to go with a "semantic-lite" where breaking changes and major features aren't the rule with point releases but can still happen in old enough/deprecated areas. It does seem more needless though in cases like this granted, unlike other examples it's not really clear why they'd do this now rather than 12.0. Not as if Python 2.7 was a spring chicken last year either, support ended in 2020 and that was like 11 years after release already? Heck, why not 11.0?
- marcellus23 5y ago
  What am I missing? When did Apple ever state they used semantic versioning in the first place?
  - Wowfunhappy 5y ago
    It's not necessarily strict semantic versioning. However, Apple has always had a distinction between major and minor updates. Minor updates are installed on most Macs automatically, whereas major ones are not. Major updates have longer developer preview and public beta periods. Major releases continue to receive security patches for a couple of years. If Apple isn't going to follow any types of rules, then what's even the point?
    - marcellus23 5y ago
      > It's implied in the fact that Apple has different types of updates in the first place. As far as I understand, Semantic Versioning is not a synonym for "versioning scheme", but refers to a specific scheme (https://semver.org https://semver.org). So I don't understand how Apple having any versioning scheme implies that it must be semver.
kristaps 5y ago
Well, anyone who still has critical stuff on Python 2, really has nobody but themselves to blame. Bad form? Maybe. Good riddance? Yes.
- Wowfunhappy 5y ago
  It's not really about Python itself. Let's say I have a little utility shell script I wrote ten years ago. I basically haven't touched it ever since. Inside the script is one line of python for fetching the current time with more precision than `date`, or something, which I forgot about a long time ago. When I install a major update, I test all my scripts to make sure they still work. I do not test after every point release, and I shouldn't have to!
  - diebeforei485 5y ago
    > I do not test after every point release, and I shouldn't have to! It's not every point release - it's just this one, and it's because this change was (very reasonably) delayed from 2020. 2.X can still be installed manually, so you have that workaround.
  - ctime 5y ago
    You should be testing early and often and not relying on arbitrary OS version numbers (Apple disagrees with you regarding the utility) to provide some kind of api stability or assurance. This is why docker and other hermetically sealed packaging and languages (golang) systems work by avoiding the OS implementations which must change and update as quickly as possible. The fact anyone would rely exclusively macOS level implementations and somehow expect them to remain stable and backwards compatible for any stretch of time blows my mind.
  - rovr138 5y ago
    I have a few PHP ones. I just took the opportunity to rewrite them when it was removed. The fact it worked so well for so many years is a test that it’s needed and that it should be rewritten. All software should be kept up to date. The same way software might have security issues and fixed, it can have other issues that need fixing.
dagmx 5y ago
macOS isn't quite semver unfortunately. The mid year releases are usually quite significant. While I'm not a fan of removing Python 2 mid major cycle, it's not without precedent, and they've had popups since the first Monterey release anytime anything linked against the system Python 2
chrisseaton 5y ago
> I never expect point releases to break stuff Apple doesn't claim to follow semantic versioning, which is where your expectation comes from.
- tasha0663 5y ago
  Frankly, I think the fact that it breeds this sort of expectation is a knock against semantic versioning. See also the faker/colors dumpster fire.
notimetorelax 5y ago
To be fair it's more annoying to have python default to 2.7, I have rewritten everything in python 3 years ago. So.. Yay! and good riddance.
sam0x17 5y ago
Major release are already such a pain in terms of just how many dev ecosystem things break every time. Doing it in a minor release is really a blessing in disguise -- all you have to deal with is this.
mrweasel 5y ago
They should have removed it in Sierra, if not El Capitan, in my opinion.
b3orn 5y ago
It was deprecated back in 10.15 this didn't come completely unexpected. Using it since then always had the risk of it getting removed in a major or a point release. https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes https://developer.apple.com/documentation/macos-release-note...
floatingatoll 5y ago
Apple doesn’t treat point releases that way. They have, for decades, been making breaking changes in late cycle point releases in macOS.
bdcravens 5y ago
Until recently, point releases were major releases.
deleted 5y ago
[deleted]

empthought 5y ago

The risk of unpatched vulnerabilities between now and the next "major release" far exceeds the risk of inconveniencing anyone foolish enough to rely on the system Python 2.7 installation.

necovek 5y ago
What server-oriented GNU/Linux distributions do is to keep patching those vulnerabilities themselves. If they need to do it for a year, it's not that hard.
- nicce 5y ago
  But is it worth it actually? I doubt that this MacOS version is used on servers…
  - mattl 5y ago
    Define server. Public webserver? Unlikely for sure. Office fileserver? Absolutely. Build server? Sure.
    - nicce 5y ago
      If we go to that road, how often you need Python 2 for fileserver or build server? Now, what is the percentage of that among all MacBooks on latest MacOS out there.
      - reaperducer 5y ago
        If we go to that road, how often you need Python 2 for fileserver or build server? Monthly, for me. Or more often if, like last week, a new customer required it.
      - Wowfunhappy 5y ago
        I think this mindset is dangerous. There's a really long tail of niche things people do on their computers, such that I suspect a majority of users have at least one niche need. Especially today, when Chromebooks and iPads are available for anyone who only needs basic web browsing. If you stop paying attention to the niches, they add up to a lot of people.
        nicce 5y ago
        You are right, but I would say that this is quite extreme case. This is a programming language which support ended 2 years ago. Only reason to use it is to avoid turning old code base to new one. There are some serious questions if that is really a good approach. And if it is, why you need to use pre-installed Python 2 instead of installing it by yourself?
        Wowfunhappy 5y ago
        I expect that there are users, who are not themselves developers, who are using either apps or scripts which rely on the system-installed Python 2. They likely aren't aware that they're using Python, and they may not even know what Python is. It could be one line in one shell script block in one automator action that a coworker put together five years ago. It's okay for that stuff to break. (I wish Apple would put more effort than they do into making it break less often, but that's neither here nor there.) But, it should break in a major release, when the user is prepared for things to break. It should not break in an update that was installed automatically overnight.
- deleted 5y ago
  [deleted]
throw0101a 5y ago
> The risk of unpatched vulnerabilities If a company as 'small' as (pre-IBM) Red Hat can afford to support Python 2.7, then so can Apple: * https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8-3 https://developers.redhat.com/blog/2018/11/14/python-in-rhel... * https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511 Further, if Debian has the resources to support Python 2.x, then so does multi-trillion dollar company of Apple: * https://packages.debian.org/search?keywords=python2 https://packages.debian.org/search?keywords=python2 If they wanted to announce at the June 2022 WWDC that macOS 13 wasn't going to have it, that's fine. But we're several months into macOS 12.x and such a large change is bad form.
- Redoubts 5y ago
  Maybe they can afford it, but why should they?
  - simlevesque 5y ago
    To offer a good service. To avoid breaking something the users depend on.
    - danaris 5y ago
      That's what Windows is for.
    - samtheDamned 5y ago
      Apple isn't in the business of spending excess money to avoid breaking things. If anything apple is the opposite.
    - Kalium 5y ago
      Apple supported Python 2 for two years after it was officially sunset by the Python Foundation. They've been advising that they will drop support for longer. How long is long enough to avoid breaking something the users depend on? One more year? Five years? Fifty? I think we can all agree that it's reasonable to drop support at some point, making it just a question of when and at what cost.
omnicognate 5y ago
Python 2 EOL was 2 years ago. 20 months before Monterey was released. Edit: And it hardly came out of the blue. Python 2.7 was 10 years old then and people had known they needed to get off it for years.
superkuh 5y ago
It's funny how people think old, robust software is suddenly going to spring a bunch of vulnerabilities while sitting there, static, unchanging. It's far more likely the bleeding edge python(s) are going to be getting new bugs. Old software isn't inherently more risky.
- WJW 5y ago
  Of course it's not going to get new vulnerabilities, but that doesn't mean hackers won't find previously unknown vulnerabilities that have always been there. Looking through the CVE database, core python alone has had 15 CVE reports in 2020 and 2021, and for old pythons those will never be patched. I'll never understand why people think they can write some software and it'll stay pristine forever. Even if it was had no known bugs at some point in the past, the world is a harsh place and your program, its dependencies, its programming language or even its OS can be found to be subtly broken at any moment. Even if it is not outright buggy, the world will change around you until the interfaces you depend on are no longer there. (looking at you, software program at $WORK that only works with PS/2 keyboards but not USB keyboards)
  - loeg 5y ago
    Many of those CVEs will not impact your application code, though. This is just a side effect of Python having a huge and somewhat crusty standard library.
  - Someone 5y ago
    If it is dynamically linked (probably the case, as that’s the norm on Mac OS), it might even get new vulnerabilities. The combination (old Python, new shared library) could have vulnerabilities that neither (old python, old shared library) nor (new python, new shared library) has.
  - lanstin 5y ago
    In the old days, software was like math - it had immutable, provable qualities. In the last several decades software has gradually become more and more like biology, where the core mechanisms are shrouded in mystery and we rely on observation and experiments to understand. The Star Trek game in Basic I typed into a computer is eternally true, a platonic form in a way software now no longer even aspires to be.
loeg 5y ago
I've previously worked at a vendor using Python2. Someone brought up this concern. I looked up the number of security releases we had cut in the past due to Python2 vulnerabilities -- it was zero.
- ShamelessC 5y ago
  This is the reason they are referred to as 0-day exploits and believe me, given enough time they will begin to appear.
  - loeg 5y ago
    Maybe? The timeline here is over a decade. It’s hard to imagine RCE without network facing services.
  - kortilla 5y ago
    We’re talking about a Python interpreter here. It already executes arbitrary input with the ability to write to files and make network connections. What type of vulnerability with it just sitting there as an executable do you expect?
    - ShamelessC 5y ago
      Doesn't need to be an RCE to be considered an exploit of the user's intentions. I can't fathom how people are still trying to use an EOL language or why they would even want to. Learn some new syntax, you'll live and the writing has been on the wall for like 20 years.
      - Wowfunhappy 5y ago
        I don't think a whole lot of people are writing new software in Python 2, but I think a lot of people are still running old software via Python 2. Software they didn't write themselves and wouldn't know how to modify. And that's not to say those users won't have to find something new eventually (or migrate the software to a contained environment). It just shouldn't happen in an automatically installed update.
nonethewiser 5y ago
>The risk of unpatched vulnerabilities between now and the next "major release" His point doesn't necessitate waiting. You could just classify it as a major release instead. That is not to say it should be a major release necessarily.
- Wowfunhappy 5y ago
  Right, Apple could have removed Python 2 last fall with the release of Monterrey, and I would have been neither surprised nor unhappy. I was actually kind of surprised when it was still in Big Sur.
  - diebeforei485 5y ago
    > I was actually kind of surprised when it was still in Big Sur. Removing support in the middle of 2020 would have been very unpopular.
    - Wowfunhappy 5y ago
      Then they could have done it in 2021 with the release of Monterrey. Heck, Monterrey was released before Omicron, so if we're concerned about COVID that should have been less disruptive than doing it now.
      - diebeforei485 5y ago
        This wouldn't have worked either. Lots of countries, where vaccines weren't widely available yet, were going through a huge Delta wave before and after WWDC. Now that most places have vaccines, it probably doesn't make sense to wait for the next major release because this has already been long delayed. Other factors could have also been at play - perhaps Apple Inc had a lot of internal tools on 2.X and has only recently gotten around to migrating all of those.
reaperducer 5y ago
The risk of unpatched vulnerabilities between now and the next "major release" far exceeds the risk of inconveniencing anyone foolish enough to rely on the system Python 2.7 installation. You make an assumption that the way your system and method of working is the same as everyone else on the planet. It is not. I have two tools that I use monthly which require python 2.7. The people who made the tools never updated them to work with 3. For this reason, I have a work box that I cannot upgrade. I know that Macs are aimed at end users, and not developers, but it really is getting harder and harder for me to use my Macs for the kind of work I do. Each major software update borks my virtual hosts. PHP has been removed, and because of code signing requirements, adding it back is so complicated it takes an entire day and filtering through a dozen half-baked online tutorials. No, the ones that say "Just use brew!" are not the answer unless you have a very simple job. I don't use Docker, but from what I read on HN, that's six miles of bad road, too. But as I understand the situation, that's Docker's fault, not Apple's.
- NavinF 5y ago
  The doctor says to the patient, "What seems to be the trouble?" The patient says, "It hurts when I do this." The doctor says, "Don't do that."
makecheck 5y ago
As a counter-point, my app was able to rely on the system Python 2.7 for FIFTEEN YEARS because it was an extremely stable component of the OS (and it allowed the app binary to be literally 10 megabytes). Now? I honestly can’t think of a way to release without adding something like 100-200 MB to the app bundle, consisting of an entire Python installation. With a user-facing app it is not ideal to try to say something like “just download Python and tell me where it is”.

throw0101a 5y ago

> What? In a point release? See also the breaking change of 12.3 kernel extensions with Dropbox and Microsoft OneDrive: * https://www.macrumors.com/2022/01/25/macos-12-3-cloud-storage-changes/ https://www.macrumors.com/2022/01/25/macos-12-3-cloud-storag... * https://help.dropbox.com/installs-integrations/desktop/macos-12-monterey-support https://help.dropbox.com/installs-integrations/desktop/macos...

tombert 5y ago

There's no law saying you cannot install an old version of Python 2.7 manually is there? I assumed this was just removing it from being bundled.

lanstin 5y ago
Yeah, and it’s been years or decades since you wanted to use the bundled software on MacOS for stuff that was important. Them removing Python 2 probably will fix more problems due to multiple Python installs than it will break anything. I tend to get a lot of support questions on “how to make this Python thing work on my Mac laptop” and I have seen some screwed up things.
rovr138 5y ago
Of course. Brew, docker, no idea if they have working release on the site, but that’s another possible way.

my123 5y ago

As far as I know: Apple OS naming isn't semver. They really have two OS major releases a year, Spring and Fall trains.

floydnoel 5y ago

macOS doesn’t follow SemVer. Major OS releases are often point versions.

easton 5y ago

It’s not semver, but I’m willing to bet (although I haven’t checked) that there were probably a few leftover system apps that didn’t get moved to Python 3 before 12.0 (many of the features were delayed, I’m guessing due to the pandemic their work schedule has been disrupted since Big Sur was feature frozen).

Wowfunhappy 5y ago
But see, if that is the case... Apple is a large company with lots of resources and knowledge of their internal roadmap. If it took Apple's own internal developers until now to remove their dependence on Python, then third-party developers and their users should get at least until next fall anyway. (I'm not defending the use of Python 2. I'm arguing that, as a general rule, if something takes the vendor X time, users should be given X + Y time.)

saagarjha 5y ago

It’s a mid-year release for Apple, even if marketing doesn’t indicate it in the version number.

xoa 5y ago

Sibling post mentions the kext breakage happening as well as another example, but I feel like they've been slipping on this as they've had increasing difficulty matching major features to their unbending yearly release schedule. So more and more (and this is the case with macOS 12 also, see Universal Control) we've seen big headline features announced at WWDC keynotes not manage to make it into the .0, but rather trickle in over the .1 to .3 releases. Once that rubicon was crossed having more other major/breaking changes start sliding into point releases doesn't seem too surprising I guess, even if the cultural slippage is irritating. Apple probably has to either give up strict semantic versioning for breaking changes, give up their strict release schedule, or be willing to defer announced features that don't make one major version all the way to the next. Something needs to give. Looks like they've decided to go with a "semantic-lite" where breaking changes and major features aren't the rule with point releases but can still happen in old enough/deprecated areas. It does seem more needless though in cases like this granted, unlike other examples it's not really clear why they'd do this now rather than 12.0. Not as if Python 2.7 was a spring chicken last year either, support ended in 2020 and that was like 11 years after release already? Heck, why not 11.0?

marcellus23 5y ago
What am I missing? When did Apple ever state they used semantic versioning in the first place?
- Wowfunhappy 5y ago
  It's not necessarily strict semantic versioning. However, Apple has always had a distinction between major and minor updates. Minor updates are installed on most Macs automatically, whereas major ones are not. Major updates have longer developer preview and public beta periods. Major releases continue to receive security patches for a couple of years. If Apple isn't going to follow any types of rules, then what's even the point?
  - marcellus23 5y ago
    > It's implied in the fact that Apple has different types of updates in the first place. As far as I understand, Semantic Versioning is not a synonym for "versioning scheme", but refers to a specific scheme (https://semver.org https://semver.org). So I don't understand how Apple having any versioning scheme implies that it must be semver.

kristaps 5y ago

Well, anyone who still has critical stuff on Python 2, really has nobody but themselves to blame. Bad form? Maybe. Good riddance? Yes.

Wowfunhappy 5y ago
It's not really about Python itself. Let's say I have a little utility shell script I wrote ten years ago. I basically haven't touched it ever since. Inside the script is one line of python for fetching the current time with more precision than `date`, or something, which I forgot about a long time ago. When I install a major update, I test all my scripts to make sure they still work. I do not test after every point release, and I shouldn't have to!
- diebeforei485 5y ago
  > I do not test after every point release, and I shouldn't have to! It's not every point release - it's just this one, and it's because this change was (very reasonably) delayed from 2020. 2.X can still be installed manually, so you have that workaround.
- ctime 5y ago
  You should be testing early and often and not relying on arbitrary OS version numbers (Apple disagrees with you regarding the utility) to provide some kind of api stability or assurance. This is why docker and other hermetically sealed packaging and languages (golang) systems work by avoiding the OS implementations which must change and update as quickly as possible. The fact anyone would rely exclusively macOS level implementations and somehow expect them to remain stable and backwards compatible for any stretch of time blows my mind.
- rovr138 5y ago
  I have a few PHP ones. I just took the opportunity to rewrite them when it was removed. The fact it worked so well for so many years is a test that it’s needed and that it should be rewritten. All software should be kept up to date. The same way software might have security issues and fixed, it can have other issues that need fixing.

dagmx 5y ago

macOS isn't quite semver unfortunately. The mid year releases are usually quite significant. While I'm not a fan of removing Python 2 mid major cycle, it's not without precedent, and they've had popups since the first Monterey release anytime anything linked against the system Python 2

chrisseaton 5y ago

> I never expect point releases to break stuff Apple doesn't claim to follow semantic versioning, which is where your expectation comes from.

tasha0663 5y ago
Frankly, I think the fact that it breeds this sort of expectation is a knock against semantic versioning. See also the faker/colors dumpster fire.

notimetorelax 5y ago

To be fair it's more annoying to have python default to 2.7, I have rewritten everything in python 3 years ago. So.. Yay! and good riddance.

sam0x17 5y ago

Major release are already such a pain in terms of just how many dev ecosystem things break every time. Doing it in a minor release is really a blessing in disguise -- all you have to deal with is this.

mrweasel 5y ago

They should have removed it in Sierra, if not El Capitan, in my opinion.

b3orn 5y ago

It was deprecated back in 10.15 this didn't come completely unexpected. Using it since then always had the risk of it getting removed in a major or a point release. https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes https://developer.apple.com/documentation/macos-release-note...

floatingatoll 5y ago

Apple doesn’t treat point releases that way. They have, for decades, been making breaking changes in late cycle point releases in macOS.

bdcravens 5y ago

Until recently, point releases were major releases.

deleted 5y ago

[deleted]