This is surely not the place for a long technical discussion of the problems that have to be solved to produce the macOS app. Let me just mention one item at the tip of the iceberg, ignoring, for example, how we go about making sage relocatable and self-contained, with no symlinks or rpaths pointing out of the application bundle and no absolute rpaths, as required for notarization. This is about why we can't just copy the python.org Python distribution into our Sage framework. One of our core design decisions is that we do not produce a multi-architecture app for Sage. Instead we produce two separate apps, one for Intel CPUs and one for Apple Silicon. Each of those is a download which is slightly over 1GB in size and which expands to about 3.5 GB when it is decompressed while being copied into the /Applicatons folder. Github has a size limit of 2GB for any released file, and we distribute the app as a github release asset. A universal2 dual-architecture app would not be double the size of a single-architecture app, but it would be getting uncomfortably close, and even if it is within limits it would be an inconvenience for users to have a much larger download, made larger in order to support an architecture that the user does not have.
However, the python.org distribution is a universal2 distribution. In particular, every sdist pip package built with the python.org pip will be a universal2 build, with each extension module being fat. - Marc On Sunday, April 6, 2025 at 5:11:29 PM UTC-5 Marc Culler wrote: > Nils, > > I think that your assessment of the situation is accurate, and that your > proposed solution: > > > We could just have a configure flag "--install_own_python" to allow the > prerequisite requirement to be fulfilled by > > building the python spkg; an option that would by default be off. > > would be ideal for the Sage_macOS project. I would be very happy with > that as a course of action. > > - Marc > > PS I am sure that there would still be problems building Sage with a > broken or out-of-date homebrew installation. I also would expect that the > non-existence of a "normal" system pip command on various linux systems, > including Ubuntu-24.04, will be problematic. Issues such as those would > manifest at a different stage of the build process, which might help focus > on how best to deal with them. > > > On Sunday, April 6, 2025 at 11:41:21 AM UTC-5 Nils Bruin wrote: > > It looks to me that there are two points of view here. > > 1) Having sagemath detect python version requirements and build its own if > not acceptable version is found leads to increased support requests. > > 2) The macos app should package its own python and that is conveniently > done by letting sagemath build its own python > > From what I understand, it would seem "1)" would be handled more > effectively if sage, instead of building python, would give an error about > the python version not available; preferably with some hints about where a > suitable python can be found (by the looks of it: conda or system > resources), because users would be guided towards installing python through > other means and they wouldn't ask sage-support for how to do that. > > It seems to me that for 1) it isn't so important if python occurs as an > spkg or not -- the main issue there would be resolved if the build process > would not default to initiating building python. So it would seem that it's > simply the python version detection code that can be adjusted. We could > just have a configure flag "--install_own_python" to allow the prerequisite > requirement to be fulfilled by building the python spkg; an option that > would by default be off. > > Then 2) can still get its python from the usual source. It would just have > to pass a flag to its configure. > > I realize that some opinions here are more centering on "should python3 > remain as an spkg" in sagemath, but from what I've seen it's not the code > quality or the volume in bits that is really the issue here: it's that > building python ends up happening in many cases where there's already > something else wrong in the setup or prerequisited and building python > masks that issue. So perhaps a good first step is to see if we can avoid > python-building masking such issues. > > We can then see if the costs of having the python.spkg around provide > enough benefit (for the MacOS app, by the looks of it). > > -- 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/6bb01f94-9ba5-46f2-93e1-6332231cdea8n%40googlegroups.com.
