This will unnecessarily make it more difficult to build the Sage_mac OS binary package. In order to make that package easy to install in the way that normal macOS users expect, it must be signed and notarized. In order to notarize the package it must be self-contained.
Not signing and notarizing the package would break it. So would requiring users to install a particular version of python. I do not believe Dima for a second when he says: "We constantly see support cases where users start installing Sage, and end up running into errors installing Sage's python3" Yes, people have problems sometimes. But those problems are not caused by Sage's python3 spkg, which always has built with no issues when building the Sage_macOS binary package since version 9.2. The following statement is just an attempt at obfuscation: "In particular, this happens when they try installing a stable version of Sage, which is too old for the rapid changes happening in macOS (just today 2025-03-30, we had such a case)." (There was no such problem reported on sage-support that day and no details to back up this claim.) There were about 35,000 downloads of the Sage_macOS 10.5 package prior to the release of 10.6 on Tuesday. Needless to say there were 0 issues related to the Python3 spkg, and less than 5 issues of any sort. There is nothing broken about the Python3 spkg. Don't "fix it" - Marc On Wednesday, April 2, 2025 at 12:03:12 PM UTC-5 wst...@gmail.com wrote: > On Wed, Apr 2, 2025 at 8:38 AM 'tobia...@gmx.de' via sage-devel > <sage-...@googlegroups.com> wrote: > > > > Sounds like a good idea. Installing a specific version of Python > nowadays is easy enough and there a few tools that make this experience as > smooth as possible. For example, uv uses prebuild pythons for many OS to > speed up the installation and to reduce the risk of build errors (see > https://github.com/astral-sh/python-build-standalone). I very much doubt > that sage will ever reach this level of smooth user experience and > sophistication - nor should it be an aim of a computer algebra system to > worry about this. > > > > +1 to exactly this. I was going to post exactly the same comment about > uv. That project has put a lot of work into specifically creating > easily redistributable Python installs... so other projects (like > Sage) don't have to. It makes a lot of sense these days to put > documentation effort into pointing people at good tools for installing > python, rather than maintaining our own build of python. A really > similar thing is how "make configure" in sage now suggests system > packages to install -- I just built sage 10.6 from source on some of > my favorite Linux boxes, and the experience was great. > > > So +1 if it is replaced by proper documentation using a modern and > standard tool (uv?) plus a few alternatives that usual work (system > installation, pyenv). > > > > On Tuesday, April 1, 2025 at 8:07:07 PM UTC+2 dim...@gmail.com wrote: > >> > >> On Tue, Apr 1, 2025 at 10:57 AM David Lowry-Duda <da...@lowryduda.com> > wrote: > >> > > >> > On 10:50 Tue 01 Apr 2025, Trevor Karn wrote: > >> > >This is my concern. But if there is a way to use only system python > >> > >installed following https://www.python.org/about/gettingstarted/ > without > >> > >regard to version issues, and get rid of SPKG python, then that > makes sense > >> > >to me. > >> > > >> > I think sage currently checks for python >= 3.11. I don't know what > features that uses, but this is newer than what comes with several major > distributions. For example, Ubuntu 20.04 LTS uses python 3.8 as its system > python, and Ubuntu 22.04 LTS uses python 3.10 as its system python. > >> > >> You are not limited to only one python3 on these systems, you can > >> install another, newer, python3 (it would get a suffix, like > >> python3.11) and use it just as well. > >> (for Ubuntu 20.04 LTS one can only official python3.10, and newer via > >> a ppa, but it's an outlier, and 20.04 LTS is a very old OS, not really > >> well-supported anymore, OS. In May 2025 one either has to pay extra > >> for its support, or upgrade). > >> > >> Our policies on minimal python3 versions are more or less in line with > >> what the main scientific Python packages, such as scipy, are following > >> - and they are doing just fine without bundling a python3 as a > >> sub-package. Our current 3.11 is a bit ahead of the curve ATM, but we > >> could be a bit slower, and sticky to a particularly widely adapted > >> system, like scipy does. > >> > >> Dima > >> > > >> > - DLD > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to sage-devel+...@googlegroups.com. > >> > To view this discussion visit > https://groups.google.com/d/msgid/sage-devel/Z-wMylxcLRvyborl%40icerm-dld. > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/sage-devel/7ab049d4-24b7-47d2-8076-570343e06278n%40googlegroups.com > . > > > > -- > William (http://wstein.org) > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/146a1582-bffb-4474-94b0-c12818f802afn%40googlegroups.com.
