On Sun, Apr 6, 2025 at 11:40 AM Dima Pasechnik <dimp...@gmail.com> wrote: > On 6 April 2025 11:41:21 GMT-05:00, Nils Bruin <nbr...@sfu.ca> 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. > > I repeat - it is not only increased support requests. We simply don't make > releases often enough to make sure that our stable releases build on > frequently updated OSs and other environments such as Homebrew. > I gave an example of this in this thread already. > More support requests pointing at issues with Python spkg came in in the past > 36 hours, by the way. > Sage 10.5 was broken qua building Sage Python from source already for some > time. Because the goalposts, which we don't control, have been moved in the > meantime.
+1. And Dima really puts a lot of work into helping with those support requests. > And having an installable Python in Sage is a huge extra source of confusion > for people who install Sage from source. Because it's unlike any other system > I know. Can we please be a bit less exceptional? It will only do Sagemath > good. > +1. There was a moment in time long ago when Sage might have become what Conda is. But that's just not the way things went, and we're very fortunate that all these other easy-to-install Pythons now exist. Let's just collaborate instead of compete. > > > > >2) The macos app should package its own python and that is conveniently > >done by letting sagemath build its own python > > macos app is best helped by them dealing with whatever Python they need on > their own. > > They don't need anything that works across platforms, they don't need any > pretesting of Python, they don't need to support building their app from > source. > It is their, and only their, build requirement, they > should bite the bullet and accept this evident fact. I don't think that was eloquently worded, but I agree with it. > >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. > > No, we couldn't have this. Our Python in stable releases is lagging behind > the curve. If we want a coherent package, not some sort of semi-broken fudge > we have now, we cannot have it. This is true. The current stable version of Python is 3.13, which was released in October 2024, but sage-10.6 ships with Python 3.12. I wasn't even able to find a github issue about upgrading sage to python 3.13... https://github.com/sagemath/sage/issues?q=is%3Aissue%20state%3Aopen%20python%20%20spkg%20label%3A%22c%3A%20packages%3A%20standard%22%20 The closest is this: https://github.com/sagemath/sage/issues/39163 Anyway, if I were working on Sage (I'm not!), my top priority -- by far -- would be to make it reasonable to "pip install sagemath". How? I don't care - just do whatever works. There are other projects (like pytorch and tensorflow) that are in a similar league of complexity to Sage, and they've done it. -- William > > Dima > > > > > >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/252B886E-DF2A-47A6-BD97-164FD29C1456%40gmail.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/CACLE5GAcSgSpJPa6D2CTWpDTT8N2-%2BRN_4bXpy%2B%2BYw44DxyGQg%40mail.gmail.com.
