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/4a79ec8c-e265-4f17-b0f2-a5634fdaaadcn%40googlegroups.com.
