On Sun, Apr 6, 2025 at 6:07 PM Marc Culler <marc.cul...@gmail.com> wrote: > > 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.
Homebrew, uv, etc provide single-arch Python3 just fine. > > 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. -- 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/CAAWYfq0sAKGEY4VhBiZok%3DVknTfk2XOr_2WAecG%2B%2Bc4Qbvc83A%40mail.gmail.com.
