On Thu, Apr 3, 2025 at 6:35 PM William Stein <wst...@gmail.com> wrote:
> On Thu, Apr 3, 2025 at 3:48 PM Marc Culler <marc.cul...@gmail.com> wrote: > > > > 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. > > Somebody will update the Sage macOS binary package preparation process > to install Python in a self-contained way, so that you can sign and > notarize it. Of course. And that person would be me. I am one of the three authors of that process. Remember? The point is that it is a completely unnecessary change which will not cause a reduction of the maintenance effort for sage. If anything it will create more issues. I realize that many people who build Sage want to use as many locally installed packages as possible, including their local installation of Python. Our priority is the opposite. We must use no local packages whatsoever. And we may be the only people who actually test that the self-contained Sage build still works. (That used to be a Sage priority, remember?) There are other ways to install Python instead of > building Python from source using our recipe Of course. So what? Don't fix what ain't broke. I realize that I could, essentially, replace the Python3 spkg with my own version of it. I know how to build Python. That is not the issue. I don;t think you know how much extra work that would create for me, or why, but I have a pretty good idea of that. If I thought that doing that extra work would make any noticeable difference in the maintenance load of Sage I would gladly do it. But it won't. > I just followed > https://docs.astral.sh/uv/guides/install-python/#reinstalling-python > to install Python 3.12 from that project on MacOS and ended up with > this working python (in a matter of seconds): > Sure. That is because Python is carefully maintained and their code almost always builds without issues. Yes, you need a couple of external libraries, for which Sage already has spkgs. This is the same reason why the Python3 spkg has not been the cause of any serious build problem since Sage 9.2 and probably much earlier than that. How much space does the Python that is included with Sage take? I > wonder if it is more than 48 MB. > Where did you get the weird idea that that the space used by python is an issue? > > Let's work with the wider python community (way, way) more and > leverage some of the great innovation and work that is happening, > rather than ignoring it. > Why don't you try adressing the question: what will Sage gain by doing this? More specifically, do you have even a shred of evidence that this plan will reduce Sage's maintenance load rather than increase it? There are lots of serious problems to worry about with the Sage build. This is not one of them. - Marc -- 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/CALcZXRHBJBMc7guTu6SmB_S4u0evPUPyYeMPYm58%3DZiyYxAs2g%40mail.gmail.com.
