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.
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.
>
>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.
>
>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.
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.
