macOS issues with 3.8.7rc1
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS. Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1. I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions. These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8. I suspect people in the Python application packaging/distribution space will be significantly affected by this (I know I am with PyOxidizer). Is it worth making the backport of these patches a 3.8.7 release blocker or a trigger for a special 3.8.8 release shortly thereafter? Gregory
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 <https://github.com/python/cpython/pull/22855> backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like. The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c). The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
I suspect people in the Python application packaging/distribution space will be significantly affected by this (I know I am with PyOxidizer). Is it worth making the backport of these patches a 3.8.7 release blocker or a trigger for a special 3.8.8 release shortly thereafter?
Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
On Wed, Dec 9, 2020 at 2:17 PM Ronald Oussoren via Python-Dev <python-dev@python.org> wrote:
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
Thank you for all your hard work on this! I've been in similar positions as a maintainer in the past (long work days and too tired to get to open source fixes in the evenings or on weekends). Please look after yourself -- it's better for everyone if the patch is delayed some months than to have you get burned out (or even just not enjoy contributing). Many open source contribution journeys begin with someone scratching an itch, so it's okay if there are itches for people to scratch. :D
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them. I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all.
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1? Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network? Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem? (It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from) -gps On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote:
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Dec 9, 2020 at 10:16 AM Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
I don't know if Apple has a written policy on support for older versions of macOS. Looking at https://support.apple.com/en-us/HT201222 it suggests that macOS 10.13 High Sierra got an update last month, but 10.12 has not been updated since September 2019.
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
I would be supportive of saying our support policy for macOS is up to one year after the last security update which would mean we would support 10.13 and newer which was released September 2017. (Honestly, I would be fine with 6 months since Apple seems to make security releases frequently enough to use that as an indicator that they have dropped support, but one year seems more "reasonable" as a way to not accidentally cut support off prematurely.) -Brett
-gps
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote:
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYO... Code of Conduct: http://python.org/psf/codeofconduct/
A general wish not to disadvantage those with older hardware any more than they already are? Just a shot in the dark. On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
-gps
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote:
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYO... Code of Conduct: http://python.org/psf/codeofconduct/
+1 On Wed, Dec 9, 2020 at 11:03 AM Steve Holden <steve@holdenweb.com> wrote:
A general wish not to disadvantage those with older hardware any more than they already are?
Just a shot in the dark.
On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
-gps
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote:
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYO... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7ZSZVIVU... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On 9 Dec 2020, at 19:59, Steve Holden <steve@holdenweb.com> wrote:
A general wish not to disadvantage those with older hardware any more than they already are?
Just a shot in the dark.
On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
-gps
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote: On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYO... Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7ZSZVIVU... Code of Conduct: http://python.org/psf/codeofconduct/
I wouldn’t be surprised if there’s a group of people that won’t ever upgrade to 10.15+ for variety of reasons (including loss of 32-bit application support) so there’s also that. Jakub
On Wed, Dec 9, 2020 at 12:15 PM Jakub Stasiak <jakub@stasiak.at> wrote:
I wouldn’t be surprised if there’s a group of people that won’t ever upgrade to 10.15+ for variety of reasons (including loss of 32-bit application support) so there’s also that.
In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS often needs more memory, which can be a problem (most Apple hardware is hard to add memory to). What are people supposed to do? Just throw away their expensive computer? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
The best way to deal with EOL platforms that I've seen is "best effort": do not guarantee continued operability but accept patches that fix breakages -- as long as they don't add maintenance burden beyond a comfortable level. So if there's a person willing to backport changes (and test them themselves since we're not testing on that old platform), I don't see a problem. On 10.12.2020 0:28, Guido van Rossum wrote:
On Wed, Dec 9, 2020 at 12:15 PM Jakub Stasiak <jakub@stasiak.at <mailto:jakub@stasiak.at>> wrote:
I wouldn’t be surprised if there’s a group of people that won’t ever upgrade to 10.15+ for variety of reasons (including loss of 32-bit application support) so there’s also that.
In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS often needs more memory, which can be a problem (most Apple hardware is hard to add memory to). What are people supposed to do? Just throw away their expensive computer?
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) /Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MKYINSTD... Code of Conduct: http://python.org/psf/codeofconduct/
-- Regards, Ivan
On 10/12/20 10:28 am, Guido van Rossum wrote:
In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS often needs more memory, which can be a problem
Another problem, for me at least, is that OS updates often seem to remove functionality that I like and rely on. I stuck with 10.6 for a very long time, because it did everything I wanted, and there were some third party extensions I used that stopped working in 10.7 and there were no good replacements available. -- Greg
On 10 Dec 2020, at 06:38, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 10/12/20 10:28 am, Guido van Rossum wrote:
In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS often needs more memory, which can be a problem
Another problem, for me at least, is that OS updates often seem to remove functionality that I like and rely on. I stuck with 10.6 for a very long time, because it did everything I wanted, and there were some third party extensions I used that stopped working in 10.7 and there were no good replacements available.
Luckily there are no plans to remove support for macOS versions :-) For master and 3.9 we can build on macOS 11 and deploy to macOS 10.9 and that won’t change. For 3.8 that doesn’t work yet, but backporting is just boring work. For 3.7 and earlier this will never work, those branches are closed for development. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
-- Greg _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/57DWVZDD... Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Dec 9, 2020 at 10:10 AM Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
FWIW The patches are necessary to target 10.15 when building on 11.0. So the value of the patches is very real to target audiences today, especially since many developers have already adopted 11.0 out of necessity. While I think there are merits to having a discussion around macOS version support policy, may I ask that it take place in a different thread so it doesn't derail the more immediate conversation centering around the 3.8.7 release?
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com> wrote:
On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... Code of Conduct: http://python.org/psf/codeofconduct/
On 9 Dec 2020, at 19:10, Gregory P. Smith <greg@krypto.org> wrote:
As a meta question: Is there a good reason to support binaries running on macOS earlier than ~ $latest_version-1?
Aren't systems running those old releases rather than upgrading unsupported by Apple, never to be patched, and thus not wise to even have on a network?
There’s no documented policy about which versions are supported, but N-2 would be a good guess (even if Apple mostly just publishes patches for N-1). What worries me a little about dropping older macOS versions is that I haven’t found good information about upgrade rates, but have seen annecdotes about users not upgrading or upgrading late. That said. We support older versions because its fairly easy to do and to keep supporting users stuck at older versions for other reasons.
Yes, that means some very old hardware becomes useless as Apple drops support. But that is what people signed up for when they bought it. Why should that be our problem?
(It sounds like y'all will make it work, that's great! I'm really just wondering where the motivation comes from)
The basic work is needed for N-1 (build on macOS 11, deploy to 10.15), doing the same for macOS 10.9 was fairly straightforward. This is work that needs to be done once, and is clearly labelled after that (making it easy to identify when we decide to move the minimal version forward). One reason to support 10.9 for the universal2 installers is that this allows us to move all users over, the universal2 installer can be used on all systems where the current x86_64 installers can be used and should be faster because we also (finally) enabled LTO/PGO for the macOS installer. BTW. Removing support for old versions is also work. The universal2 patches finally dropped support for weak linking a couple of APIs that were introduced in macOS 10.4, which we haven’t supported in a very long while. Ronald
-gps
On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc <gregory.szorc@gmail.com <mailto:gregory.szorc@gmail.com>> wrote: On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <ronaldoussoren@mac.com <mailto:ronaldoussoren@mac.com>> wrote:
On 8 Dec 2020, at 19:59, Gregory Szorc <gregory.szorc@gmail.com <mailto:gregory.szorc@gmail.com>> wrote:
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
Without the changes from https://github.com/python/cpython/pull/22855 <https://github.com/python/cpython/pull/22855> backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is only available on macOS 10.13 or newer [-Wunguarded-availability-new]` warnings during the build. This warning could be innocuous if there is run-time probing in place (the symbols in question are weakly linked, which is good). But if I'm reading the code correctly, run-time probing was introduced by commits like eee543722 and isn't present in 3.8.7rc1.
I don't have a machine with older macOS sitting around to test, but I'm fairly certain the lack of these patches means binaries built on macOS 11 will blow up at run-time when run on older macOS versions.
These same patches also taught CPython to build and run properly on Apple ARM hardware. I suspect some people will care about these being backported to 3.8.
We know. Backporting the relevant changes to 3.8 is taking more time than I had hoped. It doesn’t help that I’ve been busy at work and don’t have as much energy during the weekend as I’d like.
The backport to 3.9 was fairly easy because there were few changes between master and the 3.9 branch at the time. Sadly there have been conflicting changes since 3.8 was forked (in particular in posixmodule.c).
The current best practice for building binaries that work on macOS 10.9 is to build on that release (or rather, with that SDK). That doesn’t help if you want to build Universal 2 binaries though.
Thank you for your hard work devising the patches and working to backport them.
I personally care a lot about these patches and I have the technical competency to perform the backport. If you need help, I could potentially find time to hack on it. Just email me privately (or ping @indygreg on GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely cherry pick the patches for https://github.com/indygreg/python-build-standalone <https://github.com/indygreg/python-build-standalone>. And I'm sure other downstream packagers will want them as well. So having them in an unreleased 3.8 branch is better than not having them at all. _______________________________________________ Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org> To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO... <https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2PO...> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
participants (10)
-
Brett Cannon -
Greg Ewing -
Gregory P. Smith -
Gregory Szorc -
Guido van Rossum -
Ivan Pozdeev -
Jakub Stasiak -
Ronald Oussoren -
Simon Cross -
Steve Holden