PROPOSAL: remove python3 spkg from Sage

[Dima Pasechnik]

I propose to remove python3 (and sqlite - which has no other consumers)
from the list of Sage spkgs (packages).
Anno 2025 one has sufficiently many non-Sage ways to make sure a good
enough python3 is available for use with Sage.

We constantly see support cases where users start installing Sage, and
end up running into errors installing Sage's python3. In particular,
this happens when they try installing a stable version of Sage, which
is too old for the rapid changes happening in macOS (just today
2025-03-30, we had such a case). One less footgun will only be good.

Dima

[Emmanuel Charpentier]

Wouldn't that entail to have to maintain support for a wider selection of Python versions ?

[Dima Pasechnik]

On Mon, Mar 31, 2025 at 7:55 AM Emmanuel Charpentier
<emanuel.c...@gmail.com> wrote:
>
> Wouldn't that entail to have to maintain support for a wider selection of Python versions ?

Not bigger than at present.

>
> Le lundi 31 mars 2025 à 05:05:51 UTC+2, dim...@gmail.com a écrit :
>>
>> I propose to remove python3 (and sqlite - which has no other consumers)
>> from the list of Sage spkgs (packages).
>> Anno 2025 one has sufficiently many non-Sage ways to make sure a good
>> enough python3 is available for use with Sage.
>>
>> We constantly see support cases where users start installing Sage, and
>> end up running into errors installing Sage's python3. In particular,
>> this happens when they try installing a stable version of Sage, which
>> is too old for the rapid changes happening in macOS (just today
>> 2025-03-30, we had such a case). One less footgun will only be good.
>>
>> Dima
>

> --
> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/a304f598-db0d-424b-a481-ff885f977487n%40googlegroups.com.

[Trevor Karn]

If a user does not already have python3 installed on their system, this proposal would make installing python3 a prerequisite for installing Sage right? Is that something that we want to make users do?

[Dima Pasechnik]

On 31 March 2025 14:36:30 GMT-05:00, Trevor Karn <> wrote:
>If a user does not already have python3 installed on their system, this
>proposal would make installing python3 a prerequisite for installing Sage
>right? Is that something that we want to make users do?

Well, Sage cannot be installed without Python3 present, anyway. To be useful for Sage's venv, Python3 in question needs to satisfy some extra conditions (not too old, not too new, has all the standard modules installed.)

This is already the case, usually, anyway.
And it's really easy to fix in the majority of cases.
In the worst case (either lack of permissions, or a very old OS), user is better off installing Sage in conda environment (which does have good Pythons) -- for building an often outdated, in Sage case, Python3 from source might be impossible.

If we care that our 6-months old "stable" versions are working, we should stop pretending that our Python3 spkg (outdated by the fact that it was released a while ago) will be installable - this is not always the case. Therefore the facility to build Python3 spkg useless and harmful to the project, it doesn't bring any value, quite the contrary.

[Michael Orlitzky]

On 2025-03-30 14:19:21, Dima Pasechnik wrote:
> I propose to remove python3 (and sqlite - which has no other consumers)
> from the list of Sage spkgs (packages).
> Anno 2025 one has sufficiently many non-Sage ways to make sure a good
> enough python3 is available for use with Sage.

This is no longer a huge issue for me because we now have a way to
install only the sage library, but I still agree in principle and it
would be nice to start cleaning out the source tree. Our python
requirements are not crazy, and we already require some version of
python to be installed. Python is available on all operating systems
from multiple sources. Building it from scratch is the worst of those
because it makes us tech support for the OS toolchain. Every "python
failed to build" report is really a "python from the OS was not
detected" report in disguise, which we first have to explain.

The other argument in favor of keeping it has been that it allows for
easy testing, by bumping the SPKG version and letting the CI run. This
is still true I guess, but

1. No one is currently doing it
2. There are several people continuously testing sage with new
dependencies using other methods
3. Shipping complexity to users to make the lives of developers
easier is the opposite of how we should do things

[Trevor Karn]

What was the original intent behind having the dual requirements of (i) a system python and (ii) a SPKG python both in Sage? What (once upon a time) did having a SKPG do that couldn't/shouldn't/wouldn't be done by the system python?

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/Z-sy8YjThruYJN7H%40mertle.

[dim...@gmail.com]

On Mon, Mar 31, 2025 at 07:37:23PM -0500, Trevor Karn wrote:
> What was the original intent behind having the dual requirements of (i) a
> system python and (ii) a SPKG python both in Sage? What (once upon a time)
> did having a SKPG do that couldn't/shouldn't/wouldn't be done by the system
> python?

Originally, Python was used for Sage setup as a convenient tool, more
powerful and easier to use than bash etc.
At some point, while Sage switched to by python3 only, it was still
possible to use python2 for setup (during the transition years many
distros lagged behind in python3 adoption).
But this is all history, so we can rely on the distros-provided python3.

Dima

[Nils Bruin]

On Monday, 31 March 2025 at 17:38:06 UTC-7 Trevor Karn wrote:

What was the original intent behind having the dual requirements of (i) a system python and (ii) a SPKG python both in Sage? What (once upon a time) did having a SKPG do that couldn't/shouldn't/wouldn't be done by the system python?

At the very start of sage (some 20 years ago) a big selling point of sage was to bundle all software necessary for sage *together* with tight version specs set between the components (really: fixed version combination, because everything was bundled). At the time this was great, because open source math software was notoriously difficult to get built. Sage was actually a fairly reliable way of getting a bunch of mathematical software actually built and usable on your machine. (Sage was about "building the car, not reinvent the wheel", so most functionality was in libraries and systems shipped, with the sage library primarily providing glue to easily commicate with the different component. So in that sense, sage really started out as a distribution)

Python wasn't as standard yet either, so a choice was made to have *some* python requirement to get things bootstrapped (I guess to avoid having to write shell scripts that would have to deal with all the subtle incompatibilities between different shells), but then build python in order to ensure we knew exactly what version to rely on for actual operation. At some point, the sage python package did have some patches included.

Python has now become much more standard and probably a bit more stable in its features too. So it may well be that the benefit from having an exact python isn't as big any more. We're not usually building gcc either.

[chris wuthrich]

Would that mean that users (like me) will have to downgrade python provided by their distribution at times - or to learn how to use multiple version of python? Maybe documentation of what is recommended for this would be necessary. In general, it could make sage less accessible to a mathematician who uses only sage, maybe only through the notebook, never python otherwise. I am not against it, but it may need some caution, not to increase the barrier to use sage for the non-developers. 

Chris

[Trevor Karn]

In general, it could make sage less accessible to a mathematician who uses only sage, maybe only through the notebook, never python otherwise. I am not against it, but it may need some caution, not to increase the barrier to use sage for the non-developers. 

This is my concern. But if there is a way to use only system python installed following https://www.python.org/about/gettingstarted/ without regard to version issues, and get rid of SPKG python, then that makes sense to me. 

On Tue, Apr 1, 2025 at 10:26 AM chris wuthrich <christian...@gmail.com> wrote:

Would that mean that users (like me) will have to downgrade python provided by their distribution at times - or to learn how to use multiple version of python? Maybe documentation of what is recommended for this would be necessary. In general, it could make sage less accessible to a mathematician who uses only sage, maybe only through the notebook, never python otherwise. I am not against it, but it may need some caution, not to increase the barrier to use sage for the non-developers. 

Chris

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/71d713db-ee03-42db-acb8-258c785c4294n%40googlegroups.com.

[David Lowry-Duda]

On 10:50 Tue 01 Apr 2025, Trevor Karn wrote:
>This is my concern. But if there is a way to use only system python
>installed following https://www.python.org/about/gettingstarted/ without
>regard to version issues, and get rid of SPKG python, then that makes sense
>to me.

I think sage currently checks for python >= 3.11. I don't know what features that uses, but this is newer than what comes with several major distributions. For example, Ubuntu 20.04 LTS uses python 3.8 as its system python, and Ubuntu 22.04 LTS uses python 3.10 as its system python.

- DLD

[Nils Bruin]

I do recall a system python upgrade on Fedora a while ago where python was replaced/updated in a way that was binary incompatible. As a result, my source-built sage was rendered non-functional. Recompiling worked but of course "make" wouldn't find which prerequisites were changed and hence which components required rebuild. So there is a consistency-managing issue with basing manually-built software on components that are automatically updated. We already have that problem, though. It may be a reason to push conda-managed environments a little more: same problem, but now only localized to conda.

These events are rare, because most python updates are binary-compatible. Version bumps in python would be another source, but at least on fedora that is mitigated by having separate packages for each python version. Hence, one would normally have several python versions on the system after a while and the flavour of python for which your sage would normally still be around.

[Dima Pasechnik]

On Tue, Apr 1, 2025 at 10:26 AM chris wuthrich
<christian...@gmail.com> wrote:
>
>

> Would that mean that users (like me) will have to downgrade python provided by their distribution at times - or to learn how to use multiple version of python?

Using multiple versions of python is not a dark art. You install it
with your package manager, e.g. you might have python3 being
python3.11, and you also have python3.12, and python3.13. Sage does
not insist on using the default (python3), it can use, say,
python3.12, just as well.
You can actually pass a specific python3 to ./configure.
Yes, this would potentially mean to install one more external package.
No big deal, we already ask for a number of these anyway.

> Maybe documentation of what is recommended for this would be necessary. In general, it could make sage less accessible to a mathematician who uses only sage, maybe only through the notebook, never python otherwise. I am not against it, but it may need some caution, not to increase the barrier to use sage for the non-developers.

Sure, a bit more docs would be added in this regard.

Sage is the only python-based maths software system out there (I don't
count things like conda or linuxbrew) which tries to bundle its own
Python. There are many much more popular than Sage systems, such as
scipy, sympy, etc., which don't do this, and are doing just fine.
(they don't try to vendor everything that's useful, and can
concentrate on the core strength, while we waste time and resourses on
vendoring python, jupyter, sphinx, etc etc)

Dima
>
> Chris
>
> --

> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/71d713db-ee03-42db-acb8-258c785c4294n%40googlegroups.com.

[Dima Pasechnik]

You are not limited to only one python3 on these systems, you can
install another, newer, python3 (it would get a suffix, like
python3.11) and use it just as well.
(for Ubuntu 20.04 LTS one can only official python3.10, and newer via
a ppa, but it's an outlier, and 20.04 LTS is a very old OS, not really
well-supported anymore, OS. In May 2025 one either has to pay extra
for its support, or upgrade).

Our policies on minimal python3 versions are more or less in line with
what the main scientific Python packages, such as scipy, are following
- and they are doing just fine without bundling a python3 as a
sub-package. Our current 3.11 is a bit ahead of the curve ATM, but we
could be a bit slower, and sticky to a particularly widely adapted
system, like scipy does.

Dima
>
> - DLD
>
> --

> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/Z-wMylxcLRvyborl%40icerm-dld.

[Tobia...@gmx.de]

Sounds like a good idea. Installing a specific version of Python nowadays is easy enough and there a few tools that make this experience as smooth as possible. For example, uv uses prebuild pythons for many OS to speed up the installation and to reduce the risk of build errors (see https://github.com/astral-sh/python-build-standalone). I very much doubt that sage will ever reach this level of smooth user experience and sophistication - nor should it be an aim of a computer algebra system to worry about this.

So +1 if it is replaced by proper documentation using a modern and standard tool (uv?) plus a few alternatives that usual work (system installation, pyenv).

[William Stein]

On Wed, Apr 2, 2025 at 8:38 AM 'Tobia...@gmx.de' via sage-devel
<sage-...@googlegroups.com> wrote:
>
> Sounds like a good idea. Installing a specific version of Python nowadays is easy enough and there a few tools that make this experience as smooth as possible. For example, uv uses prebuild pythons for many OS to speed up the installation and to reduce the risk of build errors (see https://github.com/astral-sh/python-build-standalone). I very much doubt that sage will ever reach this level of smooth user experience and sophistication - nor should it be an aim of a computer algebra system to worry about this.
>

+1 to exactly this. I was going to post exactly the same comment about
uv. That project has put a lot of work into specifically creating
easily redistributable Python installs... so other projects (like
Sage) don't have to. It makes a lot of sense these days to put
documentation effort into pointing people at good tools for installing
python, rather than maintaining our own build of python. A really
similar thing is how "make configure" in sage now suggests system
packages to install -- I just built sage 10.6 from source on some of
my favorite Linux boxes, and the experience was great.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/7ab049d4-24b7-47d2-8076-570343e06278n%40googlegroups.com.



--
William (http://wstein.org)

[Marc Culler]

This will unnecessarily make it more difficult to build the Sage_mac OS binary package.   In order to make that package easy to install in the way that normal macOS users expect, it must be signed and notarized.  In order to notarize the package it must be self-contained.

Not signing and notarizing the package would break it.  So would requiring users to install a particular version of python.

I do not believe Dima for a second when he says:

"We constantly see support cases where users start installing Sage, and  end up running into errors installing Sage's python3"

Yes, people have problems sometimes. But those problems are not caused by Sage's python3 spkg, which always has built with no issues when building the Sage_macOS binary package since version 9.2.

The following statement is just an attempt at obfuscation:

"In particular,  this happens when they try installing a stable version of Sage, which  is too old for the rapid changes happening in macOS (just today 2025-03-30, we had such a case)."

(There was no such problem reported on sage-support that day and no details to back up this claim.)

There were about 35,000 downloads of the Sage_macOS 10.5 package prior to the release of 10.6 on Tuesday.  Needless to say there were 0 issues related to the Python3 spkg, and less than 5 issues of any sort.

There is nothing broken about the Python3 spkg.  Don't "fix it"

- Marc

[William Stein]

On Thu, Apr 3, 2025 at 3:48 PM Marc Culler <marc....@gmail.com> wrote:
>
> This will unnecessarily make it more difficult to build the Sage_mac OS binary package. In order to make that package easy to install in the way that normal macOS users expect, it must be signed and notarized. In order to notarize the package it must be self-contained.
>
> Not signing and notarizing the package would break it. So would requiring users to install a particular version of python.

Somebody will update the Sage macOS binary package preparation process
to install Python in a self-contained way, so that you can sign and
notarize it. There are other ways to install Python instead of
building Python from source using our recipe. As was mentioned before
by Tobia, there is a project that has got extremely good at doing
this:

https://github.com/astral-sh/python-build-standalone

They are probably much better at building Python for redistribution than we are.

I just followed
https://docs.astral.sh/uv/guides/install-python/#reinstalling-python
to install Python 3.12 from that project on MacOS and ended up with
this working python (in a matter of seconds):

black:test wstein$ du -sch
~/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/
48M /Users/williamstein/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/
48M total

How much space does the Python that is included with Sage take? I
wonder if it is more than 48 MB.

Here is some evidence that the Astral project is serious about the
problem of "building self-contained Python":

https://astral.sh/blog/python-build-standalone#whats-a-standalone-python-distribution

Etc.

Let's work with the wider python community (way, way) more and
leverage some of the great innovation and work that is happening,
rather than ignoring it.

-- William

[Marc Culler]

On Thu, Apr 3, 2025 at 6:35 PM William Stein <wst...@gmail.com> wrote:

On Thu, Apr 3, 2025 at 3:48 PM Marc Culler <marc....@gmail.com> wrote:
>
> This will unnecessarily make it more difficult to build the Sage_mac OS binary package.   In order to make that package easy to install in the way that normal macOS users expect, it must be signed and notarized.  In order to notarize the package it must be self-contained.
>
> Not signing and notarizing the package would break it.  So would requiring users to install a particular version of python.

Somebody will update the Sage macOS binary package preparation process
to install Python in a self-contained way, so that you can sign and
notarize it.

Of course.  And that person would be me.  I am one of the three authors of that process.  Remember?  The point is that it is a completely unnecessary change which will not cause a reduction of the maintenance effort for sage.  If anything it will create more issues.  I realize that many people who build Sage want to use as many locally installed packages as possible, including their local installation of Python.  Our priority is the opposite.   We must use no local packages whatsoever.  And we may be the only people who actually test that the self-contained Sage build still works.  (That used to be a Sage priority, remember?)

There are other ways to install Python instead of
building Python from source using our recipe

Of course.  So what?  Don't fix what ain't broke.

I realize that I could, essentially, replace the Python3 spkg with my own version of it.  I know how to build Python. That is not the issue.  I don;t think you know how much extra work that would create for me, or why, but I have a pretty good idea of that. If I thought that doing that extra work would make any noticeable difference in the maintenance load of Sage I would gladly do it.  But it won't.

I just followed
https://docs.astral.sh/uv/guides/install-python/#reinstalling-python
to install Python 3.12 from that project on MacOS and ended up with
this working python (in a matter of seconds):

Sure.  That is because Python is carefully maintained and their code almost always builds without issues.  Yes, you need a couple of external libraries, for which Sage already has spkgs.  This is the same reason why the Python3 spkg has not been the cause of any serious build problem since Sage 9.2 and probably much earlier than that.

How much space does the Python that is included with Sage take?  I
wonder if it is more than 48 MB.

Where did you get the weird idea that that the space used by python is an issue?

Let's work with the wider python community (way, way) more and
leverage some of the great innovation and work that is happening,
rather than ignoring it.

Why don't you try adressing the question: what will Sage gain by doing this?  More specifically, do you have even a shred of evidence that this plan will reduce Sage's maintenance load rather than increase it?

There are lots of serious problems to worry about with the Sage build.  This is not one of them.

- Marc

[Dima Pasechnik]

On 3 April 2025 17:48:00 GMT-05:00, Marc Culler <marc....@gmail.com> wrote:
>This will unnecessarily make it more difficult to build the Sage_mac OS
>binary package. In order to make that package easy to install in the way
>that normal macOS users expect, it must be signed and notarized. In order
>to notarize the package it must be self-contained.

Fine, install Python from python.org (which is easier than building
our Python spkg from source), or any other way, and package it
instead.
Problem solved.

Dima

[Marc Culler]

Actually, that does not even come close to solving the problem.

You don't have any experience with building the Sage_macOS package, obviously, so you don't know what the problems are.

- Marc

[Trevor Karn]

Maybe we can all take a breath here. Everyone here is passionate about making Sage as good as it can be. This seems to be getting a bit too heated right now.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/75629f0f-59fe-4680-9151-ab3d673566fdn%40googlegroups.com.

[William Stein]

On Thu, Apr 3, 2025 at 7:06 PM Trevor Karn <trevor...@gmail.com> wrote:
>
> Maybe we can all take a breath here. Everyone here is passionate about making Sage as good as it can be. This seems to be getting a bit too heated right now.
>

+1 - I just wanted to offer some helpful links and support, and now I
feel like I'm being "flame baited. I'm out.

William

>
> On Thu, Apr 3, 2025 at 8:55 PM Marc Culler <marc....@gmail.com> wrote:
>>
>> Actually, that does not even come close to solving the problem.
>>
>> You don't have any experience with building the Sage_macOS package, obviously, so you don't know what the problems are.
>>
>> - Marc
>>
>> On Thursday, April 3, 2025 at 8:45:48 PM UTC-5 dim...@gmail.com wrote:
>>>
>>> On 3 April 2025 17:48:00 GMT-05:00, Marc Culler <marc....@gmail.com> wrote:
>>> >This will unnecessarily make it more difficult to build the Sage_mac OS
>>> >binary package. In order to make that package easy to install in the way
>>> >that normal macOS users expect, it must be signed and notarized. In order
>>> >to notarize the package it must be self-contained.
>>>
>>> Fine, install Python from python.org (which is easier than building
>>> our Python spkg from source), or any other way, and package it
>>> instead.
>>> Problem solved.
>>>
>>> Dima
>>
>> --
>> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/75629f0f-59fe-4680-9151-ab3d673566fdn%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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAJ6VCMBsC9Uq_vO7AXQNUKWaptaRu%3D0rRm9EnSQToGhsmnTHtw%40mail.gmail.com.



--
William (http://wstein.org)

[Dima Pasechnik]

On Thu, Apr 3, 2025 at 5:48 PM Marc Culler <marc....@gmail.com> wrote:
>
> This will unnecessarily make it more difficult to build the Sage_mac OS binary package. In order to make that package easy to install in the way that normal macOS users expect, it must be signed and notarized. In order to notarize the package it must be self-contained.
>
> Not signing and notarizing the package would break it. So would requiring users to install a particular version of python.
>
> I do not believe Dima for a second when he says:

This is pure and undiluted slander. Please stop at once.

Dima

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/146a1582-bffb-4474-94b0-c12818f802afn%40googlegroups.com.

[David Roe]

On Thu, Apr 3, 2025 at 10:12 PM William Stein <wst...@gmail.com> wrote:

On Thu, Apr 3, 2025 at 7:06 PM Trevor Karn <trevor...@gmail.com> wrote:
>
> Maybe we can all take a breath here. Everyone here is passionate about making Sage as good as it can be. This seems to be getting a bit too heated right now.
>

+1  - I just wanted to offer some helpful links and support, and now I
feel like I'm being "flame baited.   I'm out.

I agree with Trevor; everyone needs to be respectful, especially if they feel strongly about the topic being discussed.  Dima and Marc are both contributing greatly to the Sage project in many ways, but the relevant ones right now are that

1. Dima is the person most likely to respond when users come to either sage-devel or sage-support and ask for help with build problems.  This is extremely valuable to the project.

2. Marc maintains our Mac application, which makes Sage easy to install and use on Macs.  This is extremely valuable to the project.

Dima started this thread because he believes that the Python spkg in Sage is making the support he's providing users harder.  Marc believes that this change would make his work more difficult.  As a community, we need to make a decision about what to do with this proposal, but rather than thinking about it as picking a side, we should think about what the costs are on each side and how we can help mitigate them and help Dima and Marc.

Concretely, Dima, can you expand a bit on how the Python spkg was complicating the build situation here?  Marc, what would be involved in building a signed Mac app if we needed to include Python in another way than an spkg?

I appreciate what both of you are doing, as I'm sure that everyone else does as well.

David

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CACLE5GAsvDby%3DQMz6im%2BOJw4rkDn%3DswBUzaQw8x6LN5%3DGH_K%2BA%40mail.gmail.com.

[William Stein]

On Fri, Apr 4, 2025 at 8:50 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
> On Thu, Apr 3, 2025 at 5:48 PM Marc Culler <marc....@gmail.com> wrote:
> >
> > This will unnecessarily make it more difficult to build the Sage_mac OS binary package. In order to make that package easy to install in the way that normal macOS users expect, it must be signed and notarized. In order to notarize the package it must be self-contained.
> >
> > Not signing and notarizing the package would break it. So would requiring users to install a particular version of python.
> >
> > I do not believe Dima for a second when he says:
>
> This is pure and undiluted slander. Please stop at once.

+1

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq195%3DUiGkY5%2BsfZzVs_2Wi%3Du2d42cN0pB4Ma-YW-DkaYg%40mail.gmail.com.



--
William (http://wstein.org)

[Trevor Karn]

Dima started this thread because he believes that the Python spkg in Sage is making the support he's providing users harder.  Marc believes that this change would make his work more difficult.  As a community, we need to make a decision about what to do with this proposal, but rather than thinking about it as picking a side, we should think about what the costs are on each side and how we can help mitigate them and help Dima and Marc.

 

Concretely, Dima, can you expand a bit on how the Python spkg was complicating the build situation here?  Marc, what would be involved in building a signed Mac app if we needed to include Python in another way than an spkg?

 

I appreciate what both of you are doing, as I'm sure that everyone else does as well.

+1

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CACLE5GDk43NLmKaZ4v1t-ZY3%2Beoybs3a7%3DahFRh%2Bj8TPkuwqjg%40mail.gmail.com.

[dim...@gmail.com]

I did as you instructed but the build again failed as it failed to load ssl 

this is the last few lines of log file 

vishalshahi@Vishals-MacBook-Air-2 pkgs % sudo less  /Users/vishalshahi/Desktop/sage/sage/logs/pkgs/python3-3.12.5.log

Password:

[spkg-build] Could not build the ssl module!

[spkg-build] Python requires a OpenSSL 1.1.1 or newer

[spkg-build] 

[spkg-build] Checked 111 modules (31 built-in, 75 shared, 2 n/a on macosx-15.3-arm64, 0 disabled, 3 missing, 0 failed on import)

[spkg-build] Testing importing of various modules...

[spkg-build] ctypes module imported OK

[spkg-build] math module imported OK

[spkg-build] hashlib module imported OK

[spkg-build] <string>:1: DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13

[spkg-build] crypt module imported OK

[spkg-build] socket module imported OK

[spkg-build] zlib module imported OK

[spkg-build] sqlite3 module imported OK

[spkg-build] Traceback (most recent call last):

[spkg-build]   File "<string>", line 1, in <module>

[spkg-build]   File "/Users/vishalshahi/Desktop/sage/sage/local/var/lib/sage/venv-python3.12.5/var/tmp/sage/build/python3-3.12.5/src/Lib/ssl.py", line 100, in <module>

[spkg-build]     import _ssl             # if we can't import it, let the error propagate

[spkg-build]     ^^^^^^^^^^^

[spkg-build] ModuleNotFoundError: No module named '_ssl'

[spkg-build] ssl module failed to import

[spkg-build] _scproxy module imported OK

[spkg-build] Error: One or more modules failed to import.

************************************************************************

Error building package python3-3.12.5

************************************************************************

Please email sage-devel (http://groups.google.com/group/sage-devel)

explaining the problem and including the log files

  /Users/vishalshahi/Desktop/sage/sage/logs/pkgs/python3-3.12.5.log

and

  /Users/vishalshahi/Desktop/sage/sage/config.log

Describe your computer, operating system, etc.

If you want to try to fix the problem yourself, *don't* just cd to

/Users/vishalshahi/Desktop/sage/sage/local/var/lib/sage/venv-python3.12.5/var/tmp/sage/build/python3-3.12.5 and type 'make' or whatever is appropriate.

Instead, the following commands setup all environment variables

correctly and load a subshell for you to debug the error:

  (cd '/Users/vishalshahi/Desktop/sage/sage/local/var/lib/sage/venv-python3.12.5/var/tmp/sage/build/python3-3.12.5' && '/Users/vishalshahi/Desktop/sage/sage/sage' --buildsh)

When you are done debugging, you can type "exit" to leave the subshell.

************************************************************************

real 2m19.398s user 1m25.244s sys 0m23.402s

(END)

 

On Sun, Mar 30, 2025 at 10:36 PM Dima Pasechnik <dim...@gmail.com> wrote:

---------- Forwarded message ---------
From: <dim...@gmail.com>
Date: Sun, Mar 30, 2025 at 11:54 AM
Subject: Re: [sage-devel] Error Building Sage
To: 'Vishal Shahi 4-Yr B.Tech.: Electronics Engg., IIT(BHU)' via
sage-devel <sage-...@googlegroups.com>


On Sun, Mar 30, 2025 at 10:39:53AM +0530, 'Vishal Shahi 4-Yr B.Tech.:
Electronics Engg., IIT(BHU)' via sage-devel wrote:
> Even after installing gsl from brew it still shows that gsl will be
> installed as no system package detected what to do ?

it's detected all right, but it depends on openblas, which is already
installed (and mixing 2 openblas installs is bad). Your log says:

openblas:                       SPKG version 0.3.28 is already installed

So, as your log says:

Checking whether SageMath should install SPKG gsl...
checking whether any of openblas is installed as or will be installed as
SPKG... yes; install gsl as well

Please run

  make distclean

and then re-run

  ./configure

This should result in using both system-wide openblas and gsl.



> vishalshahi@Vishals-MacBook-Air-2 sage % brew reinstall gsl && source
> /Users/vishalshahi/Desktop/sage/sage/.homebrew-build-env
> ==> Downloading https://ghcr.io/v2/homebrew/core/gsl/manifests/2.8
> Already downloaded:
> /Users/vishalshahi/Library/Caches/Homebrew/downloads/fd4485cda398f5fdecc616106f261ea2cd84987bc3f02422a1ae0fc0b5c6451a--gsl-2.8.bottle_manifest.json
> ==> Fetching gsl
> ==> Downloading
> https://ghcr.io/v2/homebrew/core/gsl/blobs/sha256:52e3fe781b19bd2d88986005309b2d81a2af60d17a8b3dbc3d5cad4ae2c
> Already downloaded:
> /Users/vishalshahi/Library/Caches/Homebrew/downloads/4dbb9c0506a701ad627c5cab95e17f2124ee45d5dce44b752dad124e25ad85cf--gsl--2.8.arm64_sequoia.bottle.tar.gz
> ==> Reinstalling gsl
> ==> Pouring gsl--2.8.arm64_sequoia.bottle.tar.gz
> 🍺  /opt/homebrew/Cellar/gsl/2.8: 292 files, 10.2MB
> ==> Running `brew cleanup gsl`...
> Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
> Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
> AFTER THIS I RAN make reconfigure
>
> Checking whether SageMath should install SPKG distlib...
> configure: SPKG distlib is not required on this system
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libatomic_ops...
> checking for atomic_ops >= 7.6.2... yes
> configure: will use system package and not install SPKG libatomic_ops
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gc...
> checking whether any of libatomic_ops is installed as or will be installed
> as SPKG... no
> checking whether we run on WSL... no
> checking for bdw-gc-threaded >= 7.6.4... no
> checking for bdw-gc >= 7.6.4... yes
> configure: will use system package and not install SPKG gc
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ecl...
> checking whether any of gcc gc gmp is installed as or will be installed as
> SPKG... no
> checking for ecl-config... /opt/homebrew/bin/ecl-config
> configure: will use system package and not install SPKG ecl
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ntl...
> checking whether any of gmp gcc is installed as or will be installed as
> SPKG... no
> checking for NTL/ZZ.h... yes
> checking whether we can link a program using NTL... yes
> checking NTL version >= 10.3... yes
> configure: will use system package and not install SPKG ntl
> checking absolute name of <NTL/ZZ.h>... checking for NTL/ZZ.h... (cached)
> yes
> ///opt/homebrew/opt/ntl/include/NTL/ZZ.h
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ncurses...
> checking for ncurses >= 6.0... yes
> configure: will use system package and not install SPKG ncurses
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG readline...
> checking Installing ncurses? ... No.
> checking for readline >= 6.0... yes
> configure: will use system package and not install SPKG readline
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari...
> configure: pari has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG mpfr...
> checking whether any of gmp is installed as or will be installed as SPKG...
> no
> checking for mpfr.h... yes
> checking for library containing mpfr_cmpabs_ui... -lmpfr
> configure: will use system package and not install SPKG mpfr
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG flint...
> configure: flint has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG eclib...
> configure: eclib has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ecm...
> configure: ecm has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG givaro...
> configure: givaro has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG fflas_ffpack...
> checking whether any of givaro gmp openblas is installed as or will be
> installed as SPKG... yes; install fflas_ffpack as well
> configure: no suitable system package found for SPKG fflas_ffpack
> checking whether C++ compiler accepts -mavx512f -mavx512vl -mavx512dq... yes
> checking whether C++ compiler accepts -mfma... yes
> checking whether C++ compiler accepts -mfma4... yes
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ffmpeg...
> checking for ffmpeg... /opt/homebrew/bin/ffmpeg
> configure: will use system package and not install SPKG ffmpeg
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG filelock...
> configure: SPKG filelock is not required on this system
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG fplll...
> checking whether any of gcc mpfr is installed as or will be installed as
> SPKG... no
> checking for fplll >= 5.4.5 fplll <= 5.4.5... no
> configure: no suitable system package found for SPKG fplll
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG free_fonts...
> checking for FreeSerif.ttf... no
> checking for FreeSerif.otf... no
> configure: no suitable system package found for SPKG free_fonts
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG freetype...
> checking whether any of gcc libpng is installed as or will be installed as
> SPKG... no
> checking for freetype2 >= 20.0... yes
> configure: will use system package and not install SPKG freetype
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG fricas...
> checking for FriCAS >= 1.3.8...
> configure: no suitable system package found for SPKG fricas
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gap...
> configure: gap has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gengetopt...
> checking for gengetopt... /opt/homebrew/bin/gengetopt
> configure: will use system package and not install SPKG gengetopt
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gf2x...
> checking for gf2x >= 1.2... no
> checking for gf2x.h... no
> checking for library containing gf2x_mul_r... no
> configure: no suitable system package found for SPKG gf2x
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gfan...
> checking for gfan >= 0.6.2...
> configure: no suitable system package found for SPKG gfan
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG giac...
> checking whether any of pari is installed as or will be installed as
> SPKG... yes; install giac as well
> configure: no suitable system package found for SPKG giac
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG git...
> checking for git... /opt/homebrew/bin/git
> configure: will use system package and not install SPKG git
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gp2c...
> checking whether any of pari is installed as or will be installed as
> SPKG... yes; install gp2c as well
> configure: pari.cfg is $SAGE_LOCAL/lib/pari/pari.cfg
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG graphviz...
> checking for dot... dot
> checking for neato... neato
> checking for twopi... twopi
> configure: will use system package and not install SPKG graphviz
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG gsl...
> checking whether any of openblas is installed as or will be installed as
> SPKG... yes; install gsl as well
> configure: no suitable system package found for SPKG gsl
> checking 32-bit host C ABI... no
> checking for egrep -e... /usr/bin/grep -E
> checking for ELF binary format... no
> checking for the common suffixes of directories in the library search
> path... lib,lib,lib
> checking for iconv... yes
> checking for working iconv... yes
> checking how to link with libiconv... -liconv
> checking whether iconv is compatible with its POSIX signature... yes
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG iconv...
> configure: will use system package and not install SPKG iconv
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG igraph...
> checking whether any of glpk openblas gmp is installed as or will be
> installed as SPKG... yes; install igraph as well
> configure: no suitable system package found for SPKG igraph
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG imagemagick...
> checking for convert... /opt/homebrew/bin/convert
> configure: will use system package and not install SPKG imagemagick
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG iml...
> checking whether any of gmp openblas is installed as or will be installed
> as SPKG... yes; install iml as well
> configure: no suitable system package found for SPKG iml
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG info...
> checking for info... /opt/homebrew/opt/texinfo/bin/info
> checking for texi2any... /opt/homebrew/opt/texinfo/bin/texi2any
> configure: will use system package and not install SPKG info
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG isl...
> checking whether any of gmp is installed as or will be installed as SPKG...
> no
> checking for isl >= 0.20... yes
> configure: will use system package and not install SPKG isl
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG lcalc...
> checking whether any of pari is installed as or will be installed as
> SPKG... yes; install lcalc as well
> configure: no suitable system package found for SPKG lcalc
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libbraiding...
> checking if we can link against libbraiding... no
> configure: no suitable system package found for SPKG libbraiding
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libffi...
> checking for libffi... yes
> configure: will use system package and not install SPKG libffi
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libgd...
> checking whether any of gcc libpng freetype is installed as or will be
> installed as SPKG... no
> checking for gdlib >= 2.1... yes
> configure: will use system package and not install SPKG libgd
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libgraphviz...
> checking for graphviz/cgraph.h... yes
> configure: will use system package and not install SPKG libgraphviz
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libhomfly...
> checking whether any of gc is installed as or will be installed as SPKG...
> no
> checking for homfly.h... no
> configure: no suitable system package found for SPKG libhomfly
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libjpeg...
> checking for libjpeg... yes
> configure: will use system package and not install SPKG libjpeg
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG xz...
> configure: SPKG xz is not required on this system
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG liblzma...
> checking whether any of xz is installed as or will be installed as SPKG...
> no
> checking for lzma_raw_decoder in -llzma... yes
> checking for lzma.h... yes
> configure: will use system package and not install SPKG liblzma
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG nauty...
> checking for geng... /opt/homebrew/bin/geng
> checking for directg... /opt/homebrew/bin/directg
> checking for gentourng... /opt/homebrew/bin/gentourng
> checking for geng... /opt/homebrew/bin/geng
> checking for genbg... /opt/homebrew/bin/genbg
> checking for gentreeg... /opt/homebrew/bin/gentreeg
> checking for genktreeg... /opt/homebrew/bin/genktreeg
> checking for genposetg... /opt/homebrew/bin/genposetg
> configure: will use system package and not install SPKG nauty
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libnauty...
> checking whether any of nauty is installed as or will be installed as
> SPKG... no
> checking for nauty/nauty.h... yes
> checking for library containing densenauty... -lnauty
> configure: will use system package and not install SPKG libnauty
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libsemigroups...
> checking for libsemigroups >= 0.6.7... no
> configure: no suitable system package found for SPKG libsemigroups
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG libxml2...
> checking for xml2-config... /usr/bin/xml2-config
> configure: will use system package and not install SPKG libxml2
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG m4rie...
> checking whether any of m4ri is installed as or will be installed as
> SPKG... yes; install m4rie as well
> configure: no suitable system package found for SPKG m4rie
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG linbox...
> checking whether any of fflas_ffpack flint fplll givaro gmp iml m4ri m4rie
> mpfr ntl is installed as or will be installed as SPKG... yes; install
> linbox as well
> configure: no suitable system package found for SPKG linbox
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG llvm...
> configure: will use system package and not install SPKG llvm
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG lrcalc...
> checking for lrcalc/schublib.h... no
> checking for lrcalc/lrcoef.h... no
> configure: no suitable system package found for SPKG lrcalc
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG lrslib...
> checking whether any of gmp flint is installed as or will be installed as
> SPKG... yes; install lrslib as well
> configure: no suitable system package found for SPKG lrslib
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG mathjax...
> checking for MathJax-3.x... no
> configure: no suitable system package found for SPKG mathjax
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG maxima...
> checking whether any of ecl is installed as or will be installed as SPKG...
> no
> checking for Maxima >= $5.45.0... /opt/homebrew/bin/maxima
> checking if ECL can "require" the maxima module... no
> configure: no suitable system package found for SPKG maxima
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG meson...
> checking for meson >= 1.2.3... /opt/homebrew/bin/meson
> configure: will use system package and not install SPKG meson
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG mpc...
> checking whether any of mpfr is installed as or will be installed as
> SPKG... no
> checking for MPC >= 1.2.1... yes
> checking for library containing mpc_sum... -lmpc
> configure: will use system package and not install SPKG mpc
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG mpfi...
> checking whether any of mpfr is installed as or will be installed as
> SPKG... no
> checking for mpfi.h... yes
> checking for library containing mpfi_diam_abs... -lmpfi
> checking MPFI version >= 1.5... yes
> configure: will use system package and not install SPKG mpfi
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG msolve...
> checking for msolve >= 0.6.5... no
> checking for msolve... could not find working msolve
>
> configure: no suitable system package found for SPKG msolve
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ninja_build...
> checking for ninja >= 1.8.2... /opt/homebrew/bin/ninja
> configure: will use system package and not install SPKG ninja_build
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG onetbb...
> checking whether oneTBB >= 2018 is available... yes
> configure: will use system package and not install SPKG onetbb
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG python3...
> checking whether any of bzip2 liblzma libffi zlib is installed as or will
> be installed as SPKG... no
> checking for python3 >= 3.9.0, < 3.13.0 with modules sqlite3, ctypes, math,
> hashlib, socket, zlib, ssl, ensurepip and setuptools/distutils...
> checking ... whether /opt/homebrew/bin/python3 is good... no, Python 3.13.2
> is too recent
> checking ... whether
> /Library/Frameworks/Python.framework/Versions/3.12/bin/python3 is good...
> no, the version is in the supported range but cannot import one of the
> required modules: sqlite3, ctypes, math, hashlib, socket, zlib, ssl,
> ensurepip, setuptools, setuptools.extension
> checking ... whether /usr/local/bin/python3 is good... no, the version is
> in the supported range but cannot import one of the required modules:
> sqlite3, ctypes, math, hashlib, socket, zlib, ssl, ensurepip, setuptools,
> setuptools.extension
> checking ... whether /usr/bin/python3 is good... yes
> checking for python3 >= 3.9.0, < 3.13.0 with modules sqlite3, ctypes, math,
> hashlib, socket, zlib, ssl, ensurepip... /usr/bin/python3
> configure: will use system package and not install SPKG python3
> checking whether /usr/bin/python3 is configured to build multiarch
> extensions... yes; disabling it by setting ARCHFLAGS
> checking whether "-march=native" works with the C/C++ compilers configured
> for building extensions for /usr/bin/python3... yes
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG openssl...
> configure: SPKG openssl is not required on this system
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG palp...
> checking for poly.x... no
> checking for poly-4d.x... no
> checking for poly-5d.x... no
> checking for poly-6d.x... no
> checking for poly-11d.x... no
> checking for class.x... no
> checking for class-4d.x... no
> checking for class-5d.x... no
> checking for class-6d.x... no
> checking for class-11d.x... no
> checking for nef.x... no
> checking for nef-4d.x... no
> checking for nef-5d.x... no
> checking for nef-6d.x... no
> checking for nef-11d.x... no
> checking for cws.x... no
> checking for cws-4d.x... no
> checking for cws-5d.x... no
> checking for cws-6d.x... no
> checking for cws-11d.x... no
> configure: no suitable system package found for SPKG palp
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pandoc...
> checking for pandoc... /opt/homebrew/bin/pandoc
> configure: will use system package and not install SPKG pandoc
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari_elldata...
> checking installing pari? ... yes; install pari_elldata as well
> configure: no suitable system package found for SPKG pari_elldata
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari_galdata...
> configure: pari_galdata has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari_galpol...
> checking installing pari? ... yes; install pari_galpol as well
> configure: no suitable system package found for SPKG pari_galpol
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari_nftables...
> checking installing pari? ... yes; install pari_nftables as well
> configure: no suitable system package found for SPKG pari_nftables
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari_seadata...
> checking installing pari? ... yes; install pari_seadata as well
> configure: no suitable system package found for SPKG pari_seadata
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pari_seadata_small...
> configure: pari_seadata_small has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG patch...
> configure: patch has already been installed by SageMath
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG patchelf...
> checking for patchelf... /opt/homebrew/bin/patchelf
> configure: will use system package and not install SPKG patchelf
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pdf2svg...
> checking for pdf2svg... /opt/homebrew/bin/pdf2svg
> configure: will use system package and not install SPKG pdf2svg
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG perl_cpan_polymake_prereq...
> checking for perl module XML::Writer... no
> checking for perl module XML::LibXML... no
> checking for perl module XML::LibXSLT... no
> checking for perl module File::Slurp... no
> checking for perl module JSON... no
> checking for perl module SVG... no
> checking for perl module Term::ReadKey... no
> configure: no suitable system package found for SPKG
> perl_cpan_polymake_prereq
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG perl_mongodb...
> checking for perl module MongoDB... no
> configure: no suitable system package found for SPKG perl_mongodb
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG perl_term_readline_gnu...
> checking for perl module Term::ReadLine... ok
> checking Term::ReadLine module...... non-GNU
> configure: no suitable system package found for SPKG perl_term_readline_gnu
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG pkgconf...
> configure: will use system package and not install SPKG pkgconf
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG planarity...
> checking for planarity/planarity.h... no
> configure: no suitable system package found for SPKG planarity
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG polymake...
> checking for polymake-config >= 3.5... /opt/homebrew/bin/polymake-config
> checking whether libpolymake works... no
> configure: no suitable system package found for SPKG polymake
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG ppl...
> checking whether any of gcc glpk gmp is installed as or will be installed
> as SPKG... no
> checking for ppl-config... /opt/homebrew/bin/ppl-config
> checking for the Parma Polyhedra Library, version >= 1.2... yes
> configure: will use system package and not install SPKG ppl
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG primesieve...
> checking for primesieve >= 8.0... yes
> configure: will use system package and not install SPKG primesieve
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG primecount...
> checking whether any of primesieve is installed as or will be installed as
> SPKG... no
> checking for primecount >= 7.1... yes
> configure: will use system package and not install SPKG primecount
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG qhull...
> checking for qhull... /opt/homebrew/bin/qhull
> checking whether qhull's version is good enough... yes
> checking for libqhull_r/libqhull_r.h... yes
> checking for library containing qh_distplane... -lqhull_r
> configure: will use system package and not install SPKG qhull
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG rw...
> checking for rw.h... no
> checking for library containing calculate_level... no
> configure: no suitable system package found for SPKG rw
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG sbcl...
> checking for sbcl >= 1.4.16... /opt/homebrew/bin/sbcl
> configure: will use system package and not install SPKG sbcl
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG singular...
> checking whether any of gmp ntl flint readline mpfr cddlib is installed as
> or will be installed as SPKG... yes; install singular as well
> configure: no suitable system package found for SPKG singular
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG sqlite...
> configure: SPKG sqlite is not required on this system
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG suitesparse...
> checking whether any of openblas is installed as or will be installed as
> SPKG... yes; install suitesparse as well
> configure: no suitable system package found for SPKG suitesparse
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG symengine...
> checking whether any of gmp ecm flint mpc mpfr is installed as or will be
> installed as SPKG... yes; install symengine as well
> configure: no suitable system package found for SPKG symengine
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG symmetrica...
> checking for symmetrica/def.h... no
> configure: no suitable system package found for SPKG symmetrica
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG sympow...
> checking for sympow... no
> configure: no suitable system package found for SPKG sympow
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG tachyon...
> checking for tachyon... no
> configure: tachyon not found. Installing tachyon
> configure: no suitable system package found for SPKG tachyon
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG texlive...
> checking for pdflatex... no
> checking for latexmk... no
> checking for dvipng... no
> checking for latex package fontspec... no
> checking for latex package xunicode... no
> checking for latex package xltxtra... no
> checking for latex package amssymb... no
> checking for latex package amsfonts... no
> checking for latex package graphicx... no
> checking for latex package mathrsfs... no
> checking for latex package textcomp... no
> checking for latex package tikz... no
> checking for latex package tikz-qtree... no
> checking for latex package iftex... no
> checking for latex package tkz-berge... no
> checking for latex package tkz-graph... no
> checking for latex package xy... no
> checking for latex package babel... no
> checking for latex package subfigure... no
> checking for latex package hyperref... no
> checking for latex package hypcap... no
> checking for latex package xr... no
> checking for latex package tgtermes... no
> checking for latex package fncychap... no
> configure: no suitable system package found for SPKG texlive
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG texlive_luatex...
> checking for luaotfload-main.lua... no
> configure: no suitable system package found for SPKG texlive_luatex
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG xindy...
> checking for xindy... no
> configure: no suitable system package found for SPKG xindy
> -----------------------------------------------------------------------------
> Checking whether SageMath should install SPKG zeromq...
> checking whether any of gcc is installed as or will be installed as SPKG...
> no
> checking for zmq.h... yes
> checking for ZMQ version >= 4.2.5... yes
> configure: will use system package and not install SPKG zeromq
> ## -----------------------------------------------------------------------
> ##
> ## Build status for each package:
>  ##
> ## -----------------------------------------------------------------------
> ##
> 4ti2:                           no suitable system package; optional, use
> "./configure --enable-4ti2" to install SPKG version 1.6.10
> admcycles:                      no; optional pip package; use "./sage -i
> admcycles" to install
> alabaster:                      no; standard, SPKG version 0.7.16 will be
> installed
> anyio:                          no; standard, SPKG version 4.4.0 will be
> installed
> appdirs:                        not required on your platform; SPKG will
> not be installed
> appnope:                        no; standard, SPKG version 0.1.4 will be
> installed
> argon2_cffi:                    no; standard, SPKG version 21.3.0 will be
> installed
> argon2_cffi_bindings:           no; standard, SPKG version 21.2.0 will be
> installed
> arrow:                          no; standard, SPKG version 1.3.0 will be
> installed
> asttokens:                      no; standard, SPKG version 2.4.1 will be
> installed
> async_lru:                      no; standard, SPKG version 2.0.4 will be
> installed
> attrs:                          no; standard, SPKG version 23.2.0 will be
> installed
> auditwheel_or_delocate:         no; optional pip package; use "./sage -i
> auditwheel_or_delocate" to install
> awali:                          experimental, use "./configure
> --enable-awali" to install SPKG version 1.0.2-190218
> babel:                          no; standard, SPKG version 2.14.0 will be
> installed
> barvinok:                       experimental, use "./configure
> --enable-barvinok" to install SPKG version 0.41.7
> beautifulsoup4:                 no; standard, SPKG version 4.12.2 will be
> installed
> beniget:                        no; standard, SPKG version 0.4.1 will be
> installed
> benzene:                        optional, use "./configure
> --enable-benzene" to install SPKG version 20130630
> biopython:                      no; optional pip package; use "./sage -i
> biopython" to install
> bleach:                         no; standard, SPKG version 6.1.0 will be
> installed
> bliss:                          no suitable system package; optional, use
> "./configure --enable-bliss" to install SPKG version 0.77
> boost_cropped:                  using system package; SPKG will not be
> installed
> brial:                          SPKG version 1.2.8 is already installed
> buckygen:                       optional, use "./configure
> --enable-buckygen" to install SPKG version 1.1
> bzip2:                          using system package; SPKG will not be
> installed
> cachetools:                     not required on your platform; SPKG will
> not be installed
> calver:                         no; standard, SPKG version 2022.6.26 will
> be installed
> cbc:                            no suitable system package; optional, use
> "./configure --enable-cbc" to install SPKG version 2.9.4.p0
> ccache:                         optional, use "./configure --enable-ccache"
> to install SPKG version 3.3.4
> cddlib:                         using system package; SPKG will not be
> installed
> certifi:                        no; standard, SPKG version 2024.2.2 will be
> installed
> cffi:                           no; standard, SPKG version 1.15.1 will be
> installed
> chardet:                        not required on your platform; SPKG will
> not be installed
> charset_normalizer:             no; standard, SPKG version 3.3.2 will be
> installed
> clarabel:                       optional pip package; use "./sage -i
> clarabel" to install
> cliquer:                        SPKG version 1.22 is already installed
> cmake:                          using system package; SPKG will not be
> installed
> cocoalib:                       experimental, use "./configure
> --enable-cocoalib" to install SPKG version 0.99564
> colorama:                       not required on your platform; SPKG will
> not be installed
> combinatorial_designs:          standard, SPKG version 20140630.p0 is
> already installed
> comm:                           no; standard, SPKG version 0.1.4 will be
> installed
> configure:                      base, use "./configure --enable-configure"
> to install SPKG version f6ad0ecf1f4a269f5954d5487336b13f70624594
> contourpy:                      no; standard, SPKG version 1.1.1 will be
> installed
> conway_polynomials:             no; standard, SPKG version 0.10 will be
> installed
> coxeter3:                       no suitable system package; optional, use
> "./configure --enable-coxeter3" to install SPKG version
> 8ac9c71723c8ca57a836d6381aed125261e44e9e.p0
> cppy:                           no; standard, SPKG version 1.2.1 will be
> installed
> csdp:                           optional, use "./configure --enable-csdp"
> to install SPKG version 6.2.p1
> cunningham_tables:              optional, use "./configure
> --enable-cunningham_tables" to install SPKG version 1.0
> curl:                           using system package; SPKG will not be
> installed
> cvxopt:                         no suitable system package; standard, SPKG
> version 1.3.2 will be installed
> cvxpy:                          no; optional, use "./configure
> --enable-cvxpy" to install SPKG version 1.4.1
> cycler:                         no; standard, SPKG version 0.11.0 will be
> installed
> cylp:                           no; optional, use "./configure
> --enable-cylp" to install SPKG version 0.92.2
> cypari:                         no suitable system package; standard, SPKG
> version 2.2.0 will be installed
> cysignals:                      no; standard, SPKG version 1.11.4 will be
> installed
> cython:                         no; standard, SPKG version 3.0.11 will be
> installed
> d3js:                           optional, use "./configure --enable-d3js"
> to install SPKG version 3.4.8
> database_cremona_ellcurve:      optional, use "./configure
> --enable-database_cremona_ellcurve" to install SPKG version 20190911
> database_cubic_hecke:           no; optional, use "./configure
> --enable-database_cubic_hecke" to install SPKG version 2022.4.4
> database_jones_numfield:        optional, use "./configure
> --enable-database_jones_numfield" to install SPKG version 4
> database_knotinfo:              no; optional, use "./configure
> --enable-database_knotinfo" to install SPKG version 2024.10.1
> database_kohel:                 optional, use "./configure
> --enable-database_kohel" to install SPKG version 20160724
> database_mutation_class:        optional, use "./configure
> --enable-database_mutation_class" to install SPKG version 1.0
> database_odlyzko_zeta:          optional, use "./configure
> --enable-database_odlyzko_zeta" to install SPKG version 20061209
> database_stein_watkins:         optional, use "./configure
> --enable-database_stein_watkins" to install SPKG version 20110713
> database_stein_watkins_mini:    optional, use "./configure
> --enable-database_stein_watkins_mini" to install SPKG version 20070827
> database_symbolic_data:         optional, use "./configure
> --enable-database_symbolic_data" to install SPKG version 20070206
> dateutil:                       no; standard, SPKG version 2.9.0.post0 will
> be installed
> debugpy:                        no; standard, SPKG version 1.8.1 will be
> installed
> decorator:                      no; standard, SPKG version 5.1.1 will be
> installed
> deformation:                    experimental, use "./configure
> --enable-deformation" to install SPKG version 20210503
> defusedxml:                     no; standard, SPKG version 0.7.1 will be
> installed
> distlib:                        not required on your platform; SPKG will
> not be installed
> docutils:                       no; standard, SPKG version 0.21.2 will be
> installed
> dot2tex:                        no; optional, use "./configure
> --enable-dot2tex" to install SPKG version 2.11.3.p0
> dsdp:                           optional, use "./configure --enable-dsdp"
> to install SPKG version 5.8
> e_antic:                        optional, use "./configure
> --enable-e_antic" to install SPKG version 2.0.2
> ecl:                            using system package; SPKG will not be
> installed
> eclib:                          SPKG version 20231212 is already installed
> ecm:                            SPKG version 7.0.6 is already installed
> ecos_python:                    no; optional, use "./configure
> --enable-ecos_python" to install SPKG version 2.0.12
> editables:                      no; standard, SPKG version 0.5 will be
> installed
> elliptic_curves:                standard, SPKG version 0.8.1 will be
> installed
> entrypoints:                    no; standard, SPKG version 0.4 will be
> installed
> exceptiongroup:                 no; standard, SPKG version 1.2.2 will be
> installed
> execnet:                        standard, SPKG version 2.1.1 will be
> installed
> executing:                      no; standard, SPKG version 2.0.1 will be
> installed
> fastjsonschema:                 no; standard, SPKG version 2.18.0 will be
> installed
> fflas_ffpack:                   no suitable system package; standard, SPKG
> version 2.5.0+sage-2024-05-18b will be installed
> ffmpeg:                         using system package
> filelock:                       not required on your platform; SPKG will
> not be installed
> flint:                          SPKG version 3.1.3 is already installed
> flit_core:                      no; standard, SPKG version 3.9.0 will be
> installed
> fonttools:                      no; standard, SPKG version 4.42.1 will be
> installed
> fplll:                          no suitable system package; standard, SPKG
> version 5.4.5 will be installed
> fpylll:                         no suitable system package; standard, SPKG
> version 0.6.1 will be installed
> fqdn:                           no; standard, SPKG version 1.5.1 will be
> installed
> free_fonts:                     no suitable system package; optional
> freetype:                       using system package; SPKG will not be
> installed
> fricas:                         no suitable system package; optional, use
> "./configure --enable-fricas" to install SPKG version 1.3.11
> frobby:                         optional, use "./configure --enable-frobby"
> to install SPKG version 0.9.0.p2
> furo:                           no; standard, SPKG version 2024.7.18 will
> be installed
> gap:                            SPKG version 4.13.1 is already installed
> gap3:                           experimental, use "./configure
> --enable-gap3" to install SPKG version 04jul17
> gap_jupyter:                    no; optional, use "./configure
> --enable-gap_jupyter" to install SPKG version 0.9
> gap_packages:                   optional, use "./configure
> --enable-gap_packages" to install SPKG version 4.13.1
> gast:                           no; standard, SPKG version 0.5.4 will be
> installed
> gc:                             using system package; SPKG will not be
> installed
> gcc:                            using system package; SPKG will not be
> installed
> gdb:                            optional
> gengetopt:                      using system package; SPKG will not be
> installed
> gf2x:                           no suitable system package; standard, SPKG
> version 1.3.0 will be installed
> gfan:                           no suitable system package; standard, SPKG
> version 0.6.2.p1 will be installed
> gfortran:                       using system package; SPKG will not be
> installed
> giac:                           no suitable system package; standard, SPKG
> version 1.9.0.15p0 will be installed
> git:                            using system package
> github_cli:                     optional
> gitpython:                      no; optional pip package; use "./sage -i
> gitpython" to install
> givaro:                         SPKG version 4.2.0 is already installed
> glpk:                           using system package; SPKG will not be
> installed
> glucose:                        optional, use "./configure
> --enable-glucose" to install SPKG version 4.1
> gmp:                            using system package; SPKG will not be
> installed
> gmpy2:                          no; standard, SPKG version 2.2.0a1 will be
> installed
> gnulib:                         standard, SPKG version
> f9b39c4e337f1dc0dd07c4f3985c476fb875d799 will be installed
> gnumake_tokenpool:              standard, SPKG version 0.0.7 will be
> installed
> gp2c:                           no suitable system package; optional, use
> "./configure --enable-gp2c" to install SPKG version 0.0.10.p0
> graphs:                         standard, SPKG version 20210214.p0 will be
> installed
> graphviz:                       using system package
> gsl:                            no suitable system package; standard, SPKG
> version 2.7.1 will be installed
> h11:                            standard, SPKG version 0.14.0 will be
> installed
> hatchling:                      no; standard, SPKG version 1.25.0 will be
> installed
> httpcore:                       no; standard, SPKG version 1.0.5 will be
> installed
> httpx:                          no; standard, SPKG version 0.27.0 will be
> installed
> hypothesis:                     optional pip package; use "./sage -i
> hypothesis" to install
> iconv:                          using system package
> idna:                           no; standard, SPKG version 3.7 will be
> installed
> igraph:                         no suitable system package; optional, use
> "./configure --enable-igraph" to install SPKG version 0.10.12
> imagemagick:                    using system package
> imagesize:                      no; standard, SPKG version 1.4.1 will be
> installed
> iml:                            no suitable system package; standard, SPKG
> version 1.0.4p2.p2 will be installed
> importlib_metadata:             no; standard, SPKG version 7.0.1 will be
> installed
> importlib_resources:            no; standard, SPKG version 6.1.1 will be
> installed
> info:                           using system package; SPKG will not be
> installed
> iniconfig:                      standard, SPKG version 2.0.0 will be
> installed
> ipykernel:                      no; standard, SPKG version 6.27.1 will be
> installed
> ipympl:                         no; standard, SPKG version 0.9.3 will be
> installed
> ipython:                        no; standard, SPKG version 8.18.1 will be
> installed
> ipython_genutils:               no; standard, SPKG version 0.2.0 will be
> installed
> ipywidgets:                     no; standard, SPKG version 8.1.1 will be
> installed
> isl:                            using system package; SPKG will not be
> installed
> isoduration:                    no; standard, SPKG version 20.11.0 will be
> installed
> jedi:                           no; standard, SPKG version 0.19.1 will be
> installed
> jinja2:                         no; standard, SPKG version 3.1.4 will be
> installed
> jmol:                           optional, use "./configure --enable-jmol"
> to install SPKG version 14.29.52
> json5:                          no; standard, SPKG version 0.9.14 will be
> installed
> jsonpointer:                    no; standard, SPKG version 2.4 will be
> installed
> jsonschema:                     no; standard, SPKG version 4.17.3 will be
> installed
> jsonschema_specifications:      no; standard, SPKG version 2023.3.3 will be
> installed
> jupymake:                       no; optional, use "./configure
> --enable-jupymake" to install SPKG version 0.9
> jupyter_client:                 no; standard, SPKG version 8.3.1 will be
> installed
> jupyter_core:                   no; standard, SPKG version 5.3.2 will be
> installed
> jupyter_events:                 no; standard, SPKG version 0.6.3 will be
> installed
> jupyter_jsmol:                  no; optional, use "./configure
> --enable-jupyter_jsmol" to install SPKG version 2022.1.0
> jupyter_lsp:                    no; standard, SPKG version 2.2.0 will be
> installed
> jupyter_server:                 no; standard, SPKG version 2.7.3 will be
> installed
> jupyter_server_terminals:       no; standard, SPKG version 0.4.4 will be
> installed
> jupyter_sphinx:                 no; standard, SPKG version 0.5.3.p0 will be
> installed
> jupyterlab:                     no; standard, SPKG version 4.1.3 will be
> installed
> jupyterlab_mathjax2:            no; standard, SPKG version 4.0.0 will be
> installed
> jupyterlab_pygments:            no; standard, SPKG version 0.2.2 will be
> installed
> jupyterlab_server:              no; standard, SPKG version 2.24.0 will be
> installed
> jupyterlab_widgets:             no; standard, SPKG version 3.0.9 will be
> installed
> kenzo:                          optional, use "./configure --enable-kenzo"
> to install SPKG version 1.1.10
> kissat:                         optional, use "./configure --enable-kissat"
> to install SPKG version 3.1.0
> kiwisolver:                     no; standard, SPKG version 1.4.5 will be
> installed
> latte_int:                      optional, use "./configure
> --enable-latte_int" to install SPKG version 1.7.6
> lcalc:                          no suitable system package; standard, SPKG
> version 2.0.5 will be installed
> libatomic_ops:                  using system package; SPKG will not be
> installed
> libbraiding:                    no suitable system package; standard, SPKG
> version 1.2 will be installed
> libffi:                         using system package; SPKG will not be
> installed
> libgd:                          using system package; SPKG will not be
> installed
> libgraphviz:                    using system package
> libhomfly:                      no suitable system package; standard, SPKG
> version 1.02r6 will be installed
> libjpeg:                        using system package
> liblzma:                        using system package; SPKG will not be
> installed
> libnauty:                       using system package; SPKG will not be
> installed
> libogg:                         optional, use "./configure --enable-libogg"
> to install SPKG version 1.3.1.p0
> libpng:                         using system package; SPKG will not be
> installed
> libsemigroups:                  no suitable system package; optional, use
> "./configure --enable-libsemigroups" to install SPKG version 2.7.3
> libtheora:                      experimental, use "./configure
> --enable-libtheora" to install SPKG version 1.1.1
> libxml2:                        using system package
> lidia:                          optional, use "./configure --enable-lidia"
> to install SPKG version 2.3.0+latte-patches-2019-05-02
> lie:                            experimental, use "./configure
> --enable-lie" to install SPKG version 2.2.2
> linbox:                         no suitable system package; standard, SPKG
> version 1.7.0+sage-2024-05-18 will be installed
> llvm:                           not required on your platform
> lrcalc:                         no suitable system package; standard, SPKG
> version 2.1 will be installed
> lrcalc_python:                  no; standard, SPKG version 2.1 will be
> installed
> lrslib:                         no suitable system package; optional, use
> "./configure --enable-lrslib" to install SPKG version
> 071b+autotools-2021-07-13
> m4ri:                           SPKG version 20200125 is already installed
> m4rie:                          no suitable system package; standard, SPKG
> version 20200125 will be installed
> markupsafe:                     no; standard, SPKG version 2.1.5 will be
> installed
> mathics:                        no; optional pip package; use "./sage -i
> mathics" to install
> mathjax:                        no suitable system package; standard, SPKG
> version 3.2.0 will be installed
> matplotlib:                     no; standard, SPKG version 3.8.0 will be
> installed
> matplotlib_inline:              no; standard, SPKG version 0.1.6 will be
> installed
> matroid_database:               optional, use "./configure
> --enable-matroid_database" to install SPKG version 0.3
> maxima:                         no suitable system package; standard, SPKG
> version 5.47.0 will be installed
> mcqd:                           optional, use "./configure --enable-mcqd"
> to install SPKG version 1.0.p0
> meataxe:                        optional, use "./configure
> --enable-meataxe" to install SPKG version 1.0.1
> memory_allocator:               no; standard, SPKG version 0.1.4 will be
> installed
> meson:                          using system package; SPKG will not be
> installed
> meson_python:                   no; standard, SPKG version 0.15.0 will be
> installed
> mistune:                        no; standard, SPKG version 2.0.4 will be
> installed
> modular_decomposition:          experimental, use "./configure
> --enable-modular_decomposition" to install SPKG version 20100607
> modular_resolution:             optional, use "./configure
> --enable-modular_resolution" to install SPKG version 1.1
> mpc:                            using system package; SPKG will not be
> installed
> mpfi:                           using system package; SPKG will not be
> installed
> mpfr:                           using system package; SPKG will not be
> installed
> mpfrcx:                         optional, use "./configure --enable-mpfrcx"
> to install SPKG version 0.6.3
> mpmath:                         no; standard, SPKG version 1.3.0 will be
> installed
> msolve:                         no suitable system package; optional, use
> "./configure --enable-msolve" to install SPKG version 0.6.5
> nauty:                          using system package; SPKG will not be
> installed
> nbclient:                       no; standard, SPKG version 0.8.0 will be
> installed
> nbconvert:                      no; standard, SPKG version 7.9.2 will be
> installed
> nbformat:                       no; standard, SPKG version 5.9.2 will be
> installed
> ncurses:                        using system package; SPKG will not be
> installed
> nest_asyncio:                   no; standard, SPKG version 1.6.0 will be
> installed
> networkx:                       no; standard, SPKG version 3.2.1 will be
> installed
> nibabel:                        no; optional pip package; use "./sage -i
> nibabel" to install
> ninja_build:                    using system package; SPKG will not be
> installed
> normaliz:                       optional, use "./configure
> --enable-normaliz" to install SPKG version 3.10.3
> notebook:                       no; standard, SPKG version 7.1.1 will be
> installed
> notebook_shim:                  no; standard, SPKG version 0.2.3 will be
> installed
> notedown:                       no; optional, use "./configure
> --enable-notedown" to install SPKG version 1.5.1
> ntl:                            using system package; SPKG will not be
> installed
> numpy:                          no suitable system package; standard, SPKG
> version 1.26.3 will be installed
> onetbb:                         using system package; SPKG will not be
> installed
> openblas:                       SPKG version 0.3.28 is already installed
> openssl:                        not required on your platform; SPKG will
> not be installed
> ore_algebra:                    no; optional pip package; use "./sage -i
> ore_algebra" to install
> osqp_python:                    no; optional, use "./configure
> --enable-osqp_python" to install SPKG version 0.6.3
> overrides:                      no; standard, SPKG version 7.4.0 will be
> installed
> p_group_cohomology:             no; optional, use "./configure
> --enable-p_group_cohomology" to install SPKG version 3.3.3.p1
> packaging:                      no; standard, SPKG version 24.1 will be
> installed
> palp:                           no suitable system package; standard, SPKG
> version 2.11 will be installed
> pandoc:                         using system package
> pandoc_attributes:              no; optional, use "./configure
> --enable-pandoc_attributes" to install SPKG version 8bc82f6d
> pandocfilters:                  no; standard, SPKG version 1.5.0 will be
> installed
> papilo:                         optional, use "./configure --enable-papilo"
> to install SPKG version 2.2.1
> pari:                           SPKG version 2.15.5 is already installed
> pari_elldata:                   no suitable system package; optional, use
> "./configure --enable-pari_elldata" to install SPKG version 20161017
> pari_galdata:                   SPKG version 20080411.p0 is already
> installed
> pari_galpol:                    no suitable system package; optional, use
> "./configure --enable-pari_galpol" to install SPKG version 20180625
> pari_jupyter:                   no; optional, use "./configure
> --enable-pari_jupyter" to install SPKG version 1.4.3
> pari_nftables:                  no suitable system package; optional, use
> "./configure --enable-pari_nftables" to install SPKG version 20080929
> pari_seadata:                   no suitable system package; optional, use
> "./configure --enable-pari_seadata" to install SPKG version 20090618
> pari_seadata_small:             SPKG version 20090618.p0 is already
> installed
> parso:                          no; standard, SPKG version 0.8.4 will be
> installed
> patch:                          SPKG version 2.7.6 is already installed
> patchelf:                       using system package; SPKG will not be
> installed
> pathspec:                       no; standard, SPKG version 0.12.1 will be
> installed
> pdf2svg:                        using system package
> perl_cpan_polymake_prereq:      no suitable system package; optional
> perl_mongodb:                   no suitable system package; optional
> perl_term_readline_gnu:         no suitable system package; optional, use
> "./configure --enable-perl_term_readline_gnu" to install SPKG version 1.35
> pexpect:                        no; standard, SPKG version 4.9.0 will be
> installed
> phitigra:                       no; optional pip package; use "./sage -i
> phitigra" to install
> pickleshare:                    no; standard, SPKG version 0.7.5 will be
> installed
> pillow:                         no; standard, SPKG version 10.1.0 will be
> installed
> pip:                            no; standard, SPKG version 24.2 is already
> installed
> pkgconf:                        using system package; SPKG will not be
> installed
> pkgconfig:                      no; standard, SPKG version 1.5.5 will be
> installed
> planarity:                      no suitable system package; standard, SPKG
> version 3.0.1.0 will be installed
> plantri:                        optional, use "./configure
> --enable-plantri" to install SPKG version 5.3
> platformdirs:                   no; standard, SPKG version 4.2.2 will be
> installed
> pluggy:                         no; standard, SPKG version 1.5.0 will be
> installed
> ply:                            no; standard, SPKG version 3.11 will be
> installed
> polylib:                        experimental, use "./configure
> --enable-polylib" to install SPKG version 5.22.5
> polymake:                       no suitable system package; optional, use
> "./configure --enable-polymake" to install SPKG version 4.12
> polytopes_db:                   standard, SPKG version 20170220.p0 will be
> installed
> polytopes_db_4d:                optional, use "./configure
> --enable-polytopes_db_4d" to install SPKG version 1.0
> ppl:                            using system package; SPKG will not be
> installed
> pplpy:                          no suitable system package; standard, SPKG
> version 0.8.9 will be installed
> pplpy_doc:                      standard, SPKG version 0.8.9 will be
> installed
> primecount:                     using system package; SPKG will not be
> installed
> primecountpy:                   no suitable system package; standard, SPKG
> version 0.1.0 will be installed
> primesieve:                     using system package; SPKG will not be
> installed
> prometheus_client:              no; standard, SPKG version 0.14.1 will be
> installed
> prompt_toolkit:                 no; standard, SPKG version 3.0.43 will be
> installed
> psutil:                         no; standard, SPKG version 5.9.6 will be
> installed
> ptyprocess:                     no; standard, SPKG version 0.7.0 will be
> installed
> pure_eval:                      no; standard, SPKG version 0.2.2 will be
> installed
> py:                             no; standard, SPKG version 1.11.0 will be
> installed
> pybind11:                       no; standard, SPKG version 2.11.1 will be
> installed
> pybtex:                         no; optional pip package; use "./sage -i
> pybtex" to install
> pycosat:                        no; optional, use "./configure
> --enable-pycosat" to install SPKG version 0.6.3
> pycparser:                      no; standard, SPKG version 2.22 will be
> installed
> pycryptosat:                    no; optional pip package; use "./sage -i
> pycryptosat" to install
> pygments:                       no; standard, SPKG version 2.18.0 will be
> installed
> pygraphviz:                     no; optional pip package; use "./sage -i
> pygraphviz" to install
> pynormaliz:                     no; optional, use "./configure
> --enable-pynormaliz" to install SPKG version 2.20
> pyparsing:                      no; standard, SPKG version 3.1.2 will be
> installed
> pyppeteer:                      no; optional pip package; use "./sage -i
> pyppeteer" to install
> pyproject_api:                  no; standard, SPKG version 1.7.1 will be
> installed
> pyproject_hooks:                standard, SPKG version 1.1.0 will be
> installed
> pyproject_metadata:             no; standard, SPKG version 0.8.0 will be
> installed
> pyrsistent:                     no; standard, SPKG version 0.19.3 will be
> installed
> pyscipopt:                      no; optional, use "./configure
> --enable-pyscipopt" to install SPKG version 5.0.0
> pysingular:                     no; optional, use "./configure
> --enable-pysingular" to install SPKG version 0.9.7
> pytest:                         no; standard, SPKG version 8.3.2 will be
> installed
> pytest_mock:                    no; standard, SPKG version 3.14.0 will be
> installed
> pytest_xdist:                   no; standard, SPKG version 3.6.1 will be
> installed
> python3:                        using system package; SPKG will not be
> installed
> python_build:                   no; standard, SPKG version 1.2.1 will be
> installed
> python_flint:                   optional, use "./configure
> --enable-python_flint" to install SPKG version 0.6.0
> python_igraph:                  no; optional, use "./configure
> --enable-python_igraph" to install SPKG version 0.11.5
> python_json_logger:             no; standard, SPKG version 2.0.7 will be
> installed
> pythran:                        no; standard, SPKG version 0.15.0 will be
> installed
> pytz:                           no; standard, SPKG version 2023.3.post1
> will be installed
> pytz_deprecation_shim:          no; standard, SPKG version 0.1.0.post0 will
> be installed
> pyx:                            no; optional pip package; use "./sage -i
> pyx" to install
> pyyaml:                         no; standard, SPKG version 6.0.1 will be
> installed
> pyzmq:                          no; standard, SPKG version 25.1.1 will be
> installed
> qdldl_python:                   no; optional, use "./configure
> --enable-qdldl_python" to install SPKG version 0.1.5.post3
> qepcad:                         optional, use "./configure --enable-qepcad"
> to install SPKG version 1.74
> qhull:                          using system package; SPKG will not be
> installed
> r:                              optional
> r_jupyter:                      experimental, use "./configure
> --enable-r_jupyter" to install SPKG version none
> readline:                       using system package; SPKG will not be
> installed
> referencing:                    no; standard, SPKG version 0.23.0 will be
> installed
> requests:                       no; standard, SPKG version 2.32.2 will be
> installed
> rfc3339_validator:              no; standard, SPKG version 0.1.4 will be
> installed
> rfc3986_validator:              no; standard, SPKG version 0.1.1 will be
> installed
> rpy2:                           not required on your platform; SPKG will
> not be installed
> rst2ipynb:                      no; optional, use "./configure
> --enable-rst2ipynb" to install SPKG version 0.2.3
> rubiks:                         optional, use "./configure --enable-rubiks"
> to install SPKG version 20070912.p21
> rw:                             no suitable system package; standard, SPKG
> version 0.9 will be installed
> saclib:                         optional, use "./configure --enable-saclib"
> to install SPKG version 2.2.8
> sage_conf:                      standard, SPKG version 10.5 will be
> installed
> sage_docbuild:                  standard, SPKG version 10.5 will be
> installed
> sage_flatsurf:                  optional pip package; use "./sage -i
> sage_flatsurf" to install
> sage_numerical_backends_coin:   optional, use "./configure
> --enable-sage_numerical_backends_coin" to install SPKG version 10.4
> sage_numerical_backends_cplex:  optional, use "./configure
> --enable-sage_numerical_backends_cplex" to install SPKG version 10.4
> sage_numerical_backends_gurobi: optional, use "./configure
> --enable-sage_numerical_backends_gurobi" to install SPKG version 10.4
> sage_setup:                     standard, SPKG version 10.5 will be
> installed
> sage_sws2rst:                   optional, use "./configure
> --enable-sage_sws2rst" to install SPKG version 10.5
> sagelib:                        no; standard, SPKG version 10.5 will be
> installed
> sagemath_bliss:                 optional, use "./configure
> --enable-sagemath_bliss" to install SPKG version 10.5
> sagemath_categories:            optional, use "./configure
> --enable-sagemath_categories" to install SPKG version 10.5
> sagemath_coxeter3:              optional, use "./configure
> --enable-sagemath_coxeter3" to install SPKG version 10.5
> sagemath_doc_html:              standard, SPKG will be installed
> sagemath_doc_pdf:               optional, use "./configure
> --enable-sagemath_doc_pdf" to install SPKG version none
> sagemath_environment:           optional, use "./configure
> --enable-sagemath_environment" to install SPKG version 10.5
> sagemath_mcqd:                  optional, use "./configure
> --enable-sagemath_mcqd" to install SPKG version 10.5
> sagemath_meataxe:               optional, use "./configure
> --enable-sagemath_meataxe" to install SPKG version 10.5
> sagemath_objects:               optional, use "./configure
> --enable-sagemath_objects" to install SPKG version 10.5
> sagemath_repl:                  optional, use "./configure
> --enable-sagemath_repl" to install SPKG version 10.5
> sagemath_sirocco:               optional, use "./configure
> --enable-sagemath_sirocco" to install SPKG version 10.5
> sagemath_tdlib:                 optional, use "./configure
> --enable-sagemath_tdlib" to install SPKG version 10.5
> sagenb_export:                  no; standard, SPKG version 3.3 will be
> installed
> sagetex:                        no; standard, SPKG version 3.6.1 will be
> installed
> sbcl:                           using system package
> scip:                           optional, use "./configure --enable-scip"
> to install SPKG version 9.0.1
> scip_sdp:                       optional, use "./configure
> --enable-scip_sdp" to install SPKG version 4.3.0
> scipy:                          no suitable system package; standard, SPKG
> version 1.12.0 will be installed
> scs:                            no; optional, use "./configure
> --enable-scs" to install SPKG version 3.2.3
> send2trash:                     no; standard, SPKG version 1.8.3 will be
> installed
> setuptools:                     no; standard, SPKG version 73.0.1 will be
> installed
> setuptools_scm:                 no; standard, SPKG version 8.1.0 will be
> installed
> singular:                       no suitable system package; standard, SPKG
> version 4.4.0 will be installed
> singular_jupyter:               no; optional, use "./configure
> --enable-singular_jupyter" to install SPKG version 0.9.7
> sirocco:                        optional, use "./configure
> --enable-sirocco" to install SPKG version 2.1.0
> six:                            no; standard, SPKG version 1.16.0 will be
> installed
> slabbe:                         no; optional pip package; use "./sage -i
> slabbe" to install
> snappy:                         no; optional pip package; use "./sage -i
> snappy" to install
> sniffio:                        no; standard, SPKG version 1.3.1 will be
> installed
> snowballstemmer:                no; standard, SPKG version 2.2.0 will be
> installed
> soplex:                         optional, use "./configure --enable-soplex"
> to install SPKG version 7.0.1
> soupsieve:                      no; standard, SPKG version 2.5 will be
> installed
> sphinx:                         no; standard, SPKG version 7.4.7 will be
> installed
> sphinx_basic_ng:                no; standard, SPKG version 1.0.0b2 will be
> installed
> sphinx_copybutton:              no; standard, SPKG version 0.5.2 will be
> installed
> sphinx_inline_tabs:             no; standard, SPKG version 2023.4.21 will
> be installed
> sphinxcontrib_applehelp:        no; standard, SPKG version 1.0.8 will be
> installed
> sphinxcontrib_devhelp:          no; standard, SPKG version 1.0.6 will be
> installed
> sphinxcontrib_htmlhelp:         no; standard, SPKG version 2.0.5 will be
> installed
> sphinxcontrib_jsmath:           no; standard, SPKG version 1.0.1 will be
> installed
> sphinxcontrib_qthelp:           no; standard, SPKG version 1.0.7 will be
> installed
> sphinxcontrib_serializinghtml:  no; standard, SPKG version 1.1.10 will be
> installed
> sphinxcontrib_websupport:       no; standard, SPKG version 1.2.7 will be
> installed
> sqlalchemy:                     no; optional pip package; use "./sage -i
> sqlalchemy" to install
> sqlite:                         not required on your platform; SPKG will
> not be installed
> stack_data:                     no; standard, SPKG version 0.6.3 will be
> installed
> suitesparse:                    no suitable system package; standard, SPKG
> version 7.8.0 will be installed
> surf:                           experimental, use "./configure
> --enable-surf" to install SPKG version 1.0.6-gcc6
> surface_dynamics:               no; optional pip package; use "./sage -i
> surface_dynamics" to install
> symengine:                      no suitable system package; optional, use
> "./configure --enable-symengine" to install SPKG version 0.11.2
> symengine_py:                   no; optional, use "./configure
> --enable-symengine_py" to install SPKG version 0.11.0
> symmetrica:                     no suitable system package; standard, SPKG
> version 3.0.1 will be installed
> sympow:                         no suitable system package; standard, SPKG
> version 2.023.6 will be installed
> sympy:                          no; standard, SPKG version 1.13.2 will be
> installed
> tachyon:                        no suitable system package; standard, SPKG
> version 0.99.5.p0 will be installed
> tdlib:                          optional, use "./configure --enable-tdlib"
> to install SPKG version 0.9.3.p0
> terminado:                      no; standard, SPKG version 0.17.1 will be
> installed
> texlive:                        no suitable system package; optional, use
> "./configure --enable-texlive" to install SPKG version none
> texlive_luatex:                 no suitable system package; optional
> texttable:                      no; optional, use "./configure
> --enable-texttable" to install SPKG version 1.7.0
> threejs:                        standard, SPKG version r122.p0 will be
> installed
> tides:                          optional, use "./configure --enable-tides"
> to install SPKG version 2.0.p0
> tinycss2:                       no; standard, SPKG version 1.2.1 will be
> installed
> tomli:                          no; standard, SPKG version 2.0.1 will be
> installed
> topcom:                         optional, use "./configure --enable-topcom"
> to install SPKG version 1.1.2
> tornado:                        no; standard, SPKG version 6.4 will be
> installed
> tox:                            using system package; SPKG will not be
> installed
> traitlets:                      no; standard, SPKG version 5.14.3 will be
> installed
> trove_classifiers:              no; standard, SPKG version 2024.7.2 will be
> installed
> types_python_dateutil:          no; standard, SPKG version 2.9.0.20240316
> will be installed
> typing_extensions:              no; standard, SPKG version 4.12.2 will be
> installed
> tzdata:                         standard, SPKG version 2023.3 will be
> installed
> tzlocal:                        no; standard, SPKG version 5.0.1 will be
> installed
> uri_template:                   no; standard, SPKG version 1.3.0 will be
> installed
> urllib3:                        no; standard, SPKG version 2.1.0 will be
> installed
> valgrind:                       optional
> virtualenv:                     not required on your platform; SPKG will
> not be installed
> wcwidth:                        no; standard, SPKG version 0.2.12 will be
> installed
> webcolors:                      no; standard, SPKG version 1.13 will be
> installed
> webencodings:                   no; standard, SPKG version 0.5.1 will be
> installed
> websocket_client:               no; standard, SPKG version 1.6.4 will be
> installed
> wheel:                          no; standard, SPKG version 0.44.0 will be
> installed
> widgetsnbextension:             no; standard, SPKG version 4.0.9 will be
> installed
> xindy:                          no suitable system package; optional
> xz:                             not required on your platform; SPKG will
> not be installed
> zeromq:                         using system package; SPKG will not be
> installed
> zipp:                           no; standard, SPKG version 3.19.0 will be
> installed
> zlib:                           using system package; SPKG will not be
> installed
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> configure:
>
>     notice: the following SPKGs did not find equivalent system packages:
>
>         cvxopt cypari fflas_ffpack fplll fpylll gf2x gfan giac gsl iml
> lcalc libbraiding libhomfly linbox lrcalc m4rie mathjax maxima numpy palp
> planarity pplpy primecountpy rw scipy singular suitesparse symmetrica
> sympow tachyon   4ti2 _develop _recommended bliss cbc coxeter3 free_fonts
> fricas gp2c igraph libsemigroups lrslib msolve pari_elldata pari_galpol
> pari_nftables pari_seadata perl_cpan_polymake_prereq perl_mongodb
> perl_term_readline_gnu polymake symengine texlive texlive_luatex xindy
>
> checking for the package system in use... (ignoring conda because no
> environment is active) homebrew
> configure:
>
>     hint: installing the following system packages, if not
>     already present, is recommended and may avoid having to
>     build them (though some may have to be built anyway):
>
>       $ brew install fplll gsl maxima singular suite-sparse
>
>     Homebrew can issue suggestions regarding keg-only packages.
>     The following command is to automatically apply these suggestions
>     for packages relevant for Sage to make them available for the build.
>     Run it once to apply the suggestions for the current session.
>     Add it to your shell profile to apply them for all future sessions.
>
>       $ source /Users/vishalshahi/Desktop/sage/sage/.homebrew-build-env
>
> configure:
>
>     hint: installing the following system packages, if not
>     already present, may provide additional optional features:
>
>       $ brew install gnupg texinfo cbc igraph apaffenholz/polymake/polymake
> symengine
>
>     Homebrew can issue suggestions regarding keg-only packages.
>     The following command is to automatically apply these suggestions
>     for packages relevant for Sage to make them available for the build.
>     Run it once to apply the suggestions for the current session.
>     Add it to your shell profile to apply them for all future sessions.
>
>       $ source /Users/vishalshahi/Desktop/sage/sage/.homebrew-build-env
>
> configure:
>
>     hint: After installation, re-run configure using:
>
>       $ make reconfigure
>
> config.status: creating build/make/Makefile-auto
> config.status: creating build/make/Makefile
> config.status: creating src/bin/sage-env-config
> config.status: creating src/bin/sage-src-env-config
> config.status: creating build/bin/sage-build-env-config
> config.status: creating pkgs/sage-conf/_sage_conf/_conf.py
> config.status: executing depfiles commands
> config.status: executing mkdirs commands
> config.status: creating directory
> /Users/vishalshahi/Desktop/sage/sage/logs/pkgs
> config.status: creating directory local
> config.status: creating directory local/bin
> config.status: creating directory local/etc
> config.status: creating directory local/include
> config.status: creating directory local/lib
> config.status: creating directory local/lib/pkgconfig
> config.status: creating directory local/share
> config.status: creating directory local/var/lib/sage/installed
> config.status: creating directory local/var/tmp/sage/build
> config.status: executing links commands
> config.status: creating convenience symlink prefix -> local
> config.status: creating convenience symlink venv ->
> local/var/lib/sage/venv-python3.9
> vishalshahi@Vishals-MacBook-Air-2 sage %
>
> On Sun, Mar 30, 2025 at 6:13 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
> > You can install Homebrew's gsl package (so this will solve whatever
> > problem you have with building it), and many more Homebrew packages: check
> > out the last 2 pages of the output of
> >
> > ./configure
> >
> > for a list.
> >
> > We prefer not a  part of the config.log, but the whole file. You can
> > attach files here.
> >
> >
> >
> >
> > On 29 March 2025 11:41:32 GMT-05:00, "'Vishal Shahi 4-Yr B.Tech.:
> > Electronics Engg., IIT(BHU)' via sage-devel" <sage-...@googlegroups.com>
> > wrote:
> >
> >> yes i am using home brew
> >> this is config.log
> >>
> >> ne/lib/pkgconfig:/opt/homebrew/opt/openssl/lib/pkgconfig:/opt/homebrew/opt/openblas/lib/pkgconfig:/opt/homebrew/lib/pkgconfig:
> >> --no-create --no-recursion
> >>
> >>
> >> ## --------- ##
> >>
> >> ## Platform. ##
> >>
> >> ## --------- ##
> >>
> >>
> >> hostname = Vishals-MacBook-Air-2.local
> >>
> >> uname -m = arm64
> >>
> >> uname -r = 24.3.0
> >>
> >> uname -s = Darwin
> >>
> >> uname -v = Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:06 PST 2025;
> >> root:xnu-11215.81.4~3/RELEASE_ARM64_T8103
> >>
> >>
> >> /usr/bin/uname -p = arm
> >>
> >> /bin/uname -X     = unknown
> >>
> >>
> >> /bin/arch              = unknown
> >>
> >> /usr/bin/arch -k       = unknown
> >>
> >> /usr/convex/getsysinfo = unknown
> >>
> >> /usr/bin/hostinfo      = Mach kernel version:
> >>
> >>          Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:06 PST 2025;
> >> root:xnu-11215.81.4~3/RELEASE_ARM64_T8103
> >>
> >> Kernel configured for up to 8 processors.
> >>
> >> 8 processors are physically available.
> >>
> >> 8 processors are logically available.
> >>
> >> Processor type: arm64e (ARM64E)
> >>
> >> Processors active: 0 1 2 3 4 5 6 7
> >>
> >> Primary memory available: 8.00 gigabytes
> >>
> >> Default processor set: 550 tasks, 2421 threads, 8 processors
> >>
> >> Load average: 1.69, Mach factor: 6.30
> >>
> >> /bin/machine           = unknown
> >>
> >> /usr/bin/oslevel       = unknown
> >>
> >> /bin/universe          = unknown
> >>
> >>
> >> PATH: /opt/homebrew/opt/polymake/bin/
> >>
> >> PATH: /opt/homebrew/opt/texinfo/bin/
> >>
> >>
> >> /usr/bin/uname -p = arm
> >>
> >> /bin/uname -X     = unknown
> >>
> >>
> >> /bin/arch              = unknown
> >>
> >> /usr/bin/arch -k       = unknown
> >>
> >> /usr/convex/getsysinfo = unknown
> >>
> >> /usr/bin/hostinfo      = Mach kernel version:
> >>
> >>          Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:06 PST 2025;
> >> root:xnu-11215.81.4~3/RELEASE_ARM64_T8103
> >>
> >> Kernel configured for up to 8 processors.
> >>
> >> 8 processors are physically available.
> >>
> >> 8 processors are logically available.
> >>
> >> Processor type: arm64e (ARM64E)
> >>
> >> Processors active: 0 1 2 3 4 5 6 7
> >>
> >> Primary memory available: 8.00 gigabytes
> >>
> >> Default processor set: 550 tasks, 2421 threads, 8 processors
> >>
> >> Load average: 1.69, Mach factor: 6.30
> >>
> >> /bin/machine           = unknown
> >>
> >> /usr/bin/oslevel       = unknown
> >>
> >> /bin/universe          = unknown
> >>
> >>
> >> PATH: /opt/homebrew/opt/polymake/bin/
> >>
> >> PATH: /opt/homebrew/opt/texinfo/bin/
> >>
> >> PATH: /opt/homebrew/opt/bzip2/bin/
> >>
> >> PATH: /opt/homebrew/opt/polymake/bin/
> >>
> >> PATH: /opt/homebrew/opt/texinfo/bin/
> >>
> >> PATH: /opt/homebrew/opt/bzip2/bin/
> >>
> >> PATH: /Users/vishalshahi/.nvm/versions/node/v18.20.7/bin/
> >>
> >> PATH: /Users/vishalshahi/.pyenv/shims/
> >>
> >> PATH: /opt/miniconda3/condabin/
> >>
> >> PATH: /opt/homebrew/bin/
> >>
> >> PATH: /opt/homebrew/sbin/
> >>
> >> PATH: /Library/Frameworks/Python.framework/Versions/3.12/bin/
> >>
> >> PATH: /usr/local/bin/
> >>
> >> PATH: /System/Cryptexes/App/usr/bin/
> >>
> >> PATH: /usr/bin/
> >>
> >> PATH: /bin/
> >>
> >> PATH: /usr/sbin/
> >>
> >> PATH: /sbin/
> >>
> >> PATH:
> >> /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin/
> >>
> >> PATH: /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin/
> >>
> >> PATH:
> >> /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin/
> >>
> >> PATH: /Library/Apple/usr/bin/
> >>
> >> PATH: /Users/vishalshahi/.cargo/bin/
> >>
> >>
> >>
> >> ## ----------- ##
> >>
> >> ## Core tests. ##
> >>
> >> ## ----------- ##
> >>
> >>
> >> configure:5522: looking for aux files: config.guess config.sub compile
> >> config.rpath missing install-sh
> >>
> >> configure:5535:  trying ./config/
> >>
> >> configure:5564:   ./config/config.guess found
> >>
> >> configure:5564:   ./config/config.sub found
> >>
> >> configure:5564:   ./config/compile found
> >>
> >> configure:5564:   ./config/config.rpath found
> >>
> >> configure:5564:   ./config/missing found
> >>
> >> configure:5546:   ./config/install-sh found
> >>
> >> configure:5702: checking for a BSD-compatible install
> >>
> >> configure:5776: result: /opt/homebrew/bin/ginstall -c
> >>
> >> configure:5787: checking whether sleep supports fractional seconds
> >>
> >> configure:5803: result: yes
> >>
> >> configure:5806: checking filesystem timestamp resolution
> >>
> >> configure:5941: result: 2
> >>
> >> configure:5946: checking whether build environment is sane
> >>
> >> configure:5987: result: yes
> >>
> >> configure:6158: checking for a race-free mkdir -p
> >>
> >> configure:6201: result: /opt/homebrew/bin/gmkdir -p
> >>
> >> configure:6208: checking for gawk
> >>
> >> configure:6244: result: no
> >>
> >> configure:6208: checking for mawk
> >>
> >> configure:6244: result: no
> >>
> >> configure:6208: checking for nawk
> >>
> >> configure:6244: result: no
> >>
> >> configure:6208: checking for awk
> >>
> >> configure:6229: found /usr/bin/awk
> >>
> >> configure:6241: result: awk
> >>
> >> configure:6252: checking whether make sets $(MAKE)
> >>
> >> configure:6276: result: yes
> >>
> >> configure:6302: checking whether make supports nested variables
> >>
> >> configure:6321: result: yes
> >>
> >> configure:6335: checking xargs -n works
> >>
> >> configure:6351: result: yes
> >>
> >> configure:6452: checking whether to enable maintainer-specific portions
> >> of Makefiles
> >>
> >> configure:6463: result: yes
> >>
> >> configure:6492: checking whether make supports the include directive
> >>
> >> configure:6507: make -f confmf.GNU && cat confinc.out
> >>
> >> this is the am__doit target
> >>
> >> configure:6510: $? = 0
> >>
> >> configure:6529: result: yes (GNU style)
> >>
> >> configure:6606: checking for gcc
> >>
> >> configure:6627: found /usr/bin/gcc
> >>
> >> configure:6639: result: gcc
> >>
> >> configure:6998: checking for C compiler version
> >>
> >> configure:7007: gcc --version >&5
> >>
> >> Apple clang version 16.0.0 (clang-1600.0.26.6)
> >>
> >> Target: arm64-apple-darwin24.3.0
> >>
> >> Thread model: posix
> >>
> >> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> >>
> >> configure:7018: $? = 0
> >>
> >> configure:7007: gcc -v >&5
> >>
> >> Apple clang version 16.0.0 (clang-1600.0.26.6)
> >>
> >> Target: arm64-apple-darwin24.3.0
> >>
> >> Thread model: posix
> >>
> >> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> >>
> >> configure:7018: $? = 0
> >>
> >> configure:7007: gcc -V >&5
> >>
> >> clang: error: argument to '-V' is missing (expected 1 value)
> >>
> >> clang: error: no input files
> >>
> >> configure:7018: $? = 1
> >>
> >> configure:7007: gcc -qversion >&5
> >>
> >> clang: error: unknown argument '-qversion'; did you mean '--version'?
> >>
> >> clang: error: no input files
> >>
> >> configure:7018: $? = 1
> >>
> >> configure:7007: gcc -version >&5
> >>
> >> clang: error: unknown argument '-version'; did you mean '--version'?
> >>
> >> clang: error: no input files
> >>
> >> configure:7018: $? = 1
> >>
> >> configure:7038: checking whether the C compiler works
> >>
> >> configure:7060: gcc    conftest.c  >&5
> >>
> >> configure:7064: $? = 0
> >>
> >> configure:7115: result: yes
> >>
> >> configure:7119: checking for C compiler default output file name
> >>
> >> configure:7121: result: a.out
> >>
> >>
> >> Do you need more sir ?
> >>
> >>
> >>
> >> On Sat, Mar 29, 2025 at 8:56 PM Dima Pasechnik <dim...@gmail.com> wrote:
> >>
> >>> Do you use Homebrew?
> >>> Please post top-level config.log
> >>>
> >>>
> >>> On 29 March 2025 01:29:35 GMT-05:00, 'Vishal Shahi' via sage-devel <
> >>> sage-...@googlegroups.com> wrote:
> >>>
> >>>> Dear Sage Development Team,
> >>>>
> >>>> I am experiencing an issue while building Sage on my MacBook Air M1
> >>>> running macOS Sequoia. I followed all instructions outlined in the GitHub
> >>>> README, yet I continually receive an error during the build process,
> >>>> specifically when attempting to configure gsl-2.7.1.
> >>>>
> >>>> ```
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] checking host system type...
> >>>> arm-apple-darwin24.3.0
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] checking for gcc... gcc
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] checking whether the C compiler works... no
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] configure: error: in
> >>>> `/Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1/src':
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] configure: error: C compiler cannot create
> >>>> executables
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] See `config.log' for more details
> >>>>
> >>>> [gsl-2.7.1] [spkg-install]
> >>>> ********************************************************************************
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] Error configuring gsl-2.7.1 See the file
> >>>>
> >>>> [gsl-2.7.1] [spkg-install]
> >>>> /Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1/src/config.log
> >>>>
> >>>> [gsl-2.7.1] [spkg-install] for details.
> >>>>
> >>>> [gsl-2.7.1] [spkg-install]
> >>>> ********************************************************************************
> >>>>
> >>>> [gsl-2.7.1]
> >>>> ************************************************************************
> >>>>
> >>>> [gsl-2.7.1] Error installing package gsl-2.7.1
> >>>>
> >>>> [gsl-2.7.1]
> >>>> ************************************************************************
> >>>>
> >>>> [gsl-2.7.1] Please email sage-devel (
> >>>> http://groups.google.com/group/sage-devel)
> >>>>
> >>>> [gsl-2.7.1] explaining the problem and including the log files
> >>>>
> >>>> [gsl-2.7.1]
> >>>> /Users/vishalshahi/Desktop/sage/sage/logs/pkgs/gsl-2.7.1.log
> >>>>
> >>>> [gsl-2.7.1] and
> >>>>
> >>>> [gsl-2.7.1]   /Users/vishalshahi/Desktop/sage/sage/config.log
> >>>>
> >>>> [gsl-2.7.1] Describe your computer, operating system, etc.
> >>>>
> >>>> [gsl-2.7.1] If you want to try to fix the problem yourself, *don't*
> >>>> just cd to
> >>>>
> >>>> [gsl-2.7.1]
> >>>> /Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1 and
> >>>> type 'make' or whatever is appropriate.
> >>>>
> >>>> [gsl-2.7.1] Instead, the following commands setup all environment
> >>>> variables
> >>>>
> >>>> [gsl-2.7.1] correctly and load a subshell for you to debug the error:
> >>>>
> >>>> [gsl-2.7.1]   (cd
> >>>> '/Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1'
> >>>> && '/Users/vishalshahi/Desktop/sage/sage/sage' --buildsh)
> >>>>
> >>>> [gsl-2.7.1] When you are done debugging, you can type "exit" to leave
> >>>> the subshell.
> >>>>
> >>>> [gsl-2.7.1]
> >>>> ************************************************************************
> >>>>
> >>>> make[4]: *** [gsl-SAGE_LOCAL-no-deps] Error 1
> >>>>
> >>>> make[3]: ***
> >>>> [/Users/vishalshahi/Desktop/sage/sage/local/var/lib/sage/installed/gsl-2.7.1]
> >>>> Error 2
> >>>>
> >>>> make[2]: *** [all-build] Error 2
> >>>>
> >>>> ***************************************************************
> >>>>
> >>>> Error building Sage.
> >>>>
> >>>>
> >>>> The following package(s) may have failed to build (not necessarily
> >>>>
> >>>> during this run of 'make all-build'):
> >>>>
> >>>>
> >>>> * package:         gsl-2.7.1
> >>>>
> >>>>   last build time: Mar 29 11:25
> >>>>
> >>>>   log file:
> >>>> /Users/vishalshahi/Desktop/sage/sage/logs/pkgs/gsl-2.7.1.log
> >>>>
> >>>>   build directory:
> >>>> /Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1
> >>>> ```
> >>>> log file gsl
> >>>> [spkg-install] configure: error: C compiler cannot create executables
> >>>> [spkg-install] See `config.log' for more details
> >>>> [spkg-install] checking for a BSD-compatible install...
> >>>> /opt/homebrew/bin/ginstall -c
> >>>> [spkg-install] checking whether build environment is sane... yes
> >>>> [spkg-install] checking for a race-free mkdir -p...
> >>>> /opt/homebrew/bin/gmkdir -p
> >>>> [spkg-install] checking for gawk... no
> >>>> [spkg-install] checking for mawk... no
> >>>> [spkg-install] checking for nawk... no
> >>>> [spkg-install] checking for awk... awk
> >>>> [spkg-install] checking whether make sets $(MAKE)... yes
> >>>> [spkg-install] checking whether make supports nested variables... yes
> >>>> [spkg-install] checking whether to enable maintainer-specific portions
> >>>> of Makefiles... no
> >>>> [spkg-install] checking for a sed that does not truncate output...
> >>>> /usr/bin/sed
> >>>> [spkg-install] checking whether make sets $(MAKE)... (cached) yes
> >>>> [spkg-install] checking build system type... arm-apple-darwin24.3.0
> >>>> [spkg-install] checking host system type... arm-apple-darwin24.3.0
> >>>> [spkg-install] checking for gcc... gcc
> >>>> [spkg-install] checking whether the C compiler works... no
> >>>> [spkg-install] configure: error: in
> >>>> `/Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1/src':
> >>>> [spkg-install] configure: error: C compiler cannot create executables
> >>>> [spkg-install] See `config.log' for more details
> >>>> [spkg-install]
> >>>> ********************************************************************************
> >>>> [spkg-install] Error configuring gsl-2.7.1 See the file
> >>>> [spkg-install]
> >>>> /Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1/src/config.log
> >>>> [spkg-install] for details.
> >>>> [spkg-install]
> >>>> ********************************************************************************
> >>>> ************************************************************************
> >>>> Error installing package gsl-2.7.1
> >>>> ************************************************************************
> >>>> Please email sage-devel (http://groups.google.com/group/sage-devel)
> >>>> explaining the problem and including the log files
> >>>>   /Users/vishalshahi/Desktop/sage/sage/logs/pkgs/gsl-2.7.1.log
> >>>> and
> >>>>   /Users/vishalshahi/Desktop/sage/sage/config.log
> >>>> Describe your computer, operating system, etc.
> >>>> If you want to try to fix the problem yourself, *don't* just cd to
> >>>> /Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1
> >>>> and type 'make' or whatever is appropriate.
> >>>> Instead, the following commands setup all environment variables
> >>>> correctly and load a subshell for you to debug the error:
> >>>>   (cd
> >>>> '/Users/vishalshahi/Desktop/sage/sage/local/var/tmp/sage/build/gsl-2.7.1'
> >>>> && '/Users/vishalshahi/Desktop/sage/sage/sage' --buildsh)
> >>>> When you are done debugging, you can type "exit" to leave the subshell.
> >>>> ************************************************************************
> >>>> config.log
> >>>> #define HAVE_ICONV 1
> >>>> #define ICONV_CONST
> >>>> #define HAVE_ZMQ /**/
> >>>>
> >>>> configure: exit 0
> >>>>
> >>>> ## ---------------------- ##
> >>>> ## Running config.status. ##
> >>>> ## ---------------------- ##
> >>>>
> >>>> This file was extended by Sage config.status 10.5, which was
> >>>> generated by GNU Autoconf 2.72.  Invocation command line was
> >>>>
> >>>>   CONFIG_FILES    =
> >>>>   CONFIG_HEADERS  =
> >>>>   CONFIG_LINKS    =
> >>>>   CONFIG_COMMANDS =
> >>>>   $ ./config.status
> >>>>
> >>>> on Vishals-MacBook-Air-2.local
> >>>>
> >>>> config.status:4031: creating build/make/Makefile-auto
> >>>> config.status:4031: creating build/make/Makefile
> >>>> config.status:4031: creating src/bin/sage-env-config
> >>>> config.status:4031: creating src/bin/sage-src-env-config
> >>>> config.status:4031: creating build/bin/sage-build-env-config
> >>>> config.status:4031: creating pkgs/sage-conf/_sage_conf/_conf.py
> >>>> config.status:4203: executing depfiles commands
> >>>> config.status:4203: executing mkdirs commands
> >>>> config.status:4335: creating directory
> >>>> /Users/vishalshahi/Desktop/sage/sage/logs/pkgs
> >>>> config.status:4335: creating directory local
> >>>> config.status:4335: creating directory local/bin
> >>>> config.status:4335: creating directory local/etc
> >>>> config.status:4335: creating directory local/include
> >>>> config.status:4335: creating directory local/lib
> >>>> config.status:4335: creating directory local/lib/pkgconfig
> >>>> config.status:4335: creating directory local/share
> >>>> config.status:4335: creating directory local/var/lib/sage/installed
> >>>> config.status:4354: creating directory local/var/tmp/sage/build
> >>>> config.status:4203: executing links commands
> >>>> config.status:4370: creating convenience symlink prefix -> local
> >>>> config.status:4386: creating convenience symlink venv ->
> >>>> local/var/lib/sage/venv-python3.9

> >>>>
> >>>> --
> >>> 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+...@googlegroups.com.
> >>> To view this discussion visit

> >>> https://groups.google.com/d/msgid/sage-devel/EB91F382-B326-4873-B115-9EC41C53753E%40gmail.com
> >>> <https://groups.google.com/d/msgid/sage-devel/EB91F382-B326-4873-B115-9EC41C53753E%40gmail.com?utm_medium=email&utm_source=footer>

> >>> .
> >>>
> >> --
> > 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+...@googlegroups.com.
> > To view this discussion visit

> > https://groups.google.com/d/msgid/sage-devel/6AF38F98-63D7-47F3-8A08-92EF3B8B4FAA%40gmail.com
> > <https://groups.google.com/d/msgid/sage-devel/6AF38F98-63D7-47F3-8A08-92EF3B8B4FAA%40gmail.com?utm_medium=email&utm_source=footer>

> > .
> >
>
> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAL2Ch8Yd42K%2B%2B9y3_S10g%3D93fa_BUHU5pp%3DKQWobHYKB%2BAPkaA%40mail.gmail.com.

[Marc Culler]

Thank you, David.

I am driving from Denver to Chicago at the moment.  Once I get home I will be able to respond with some details about the issues that arise when packaging Sage for macOS, including why it is not possible to just run python3 setup.py py2app and end up with a Sage app.

- Marc

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAChs6_%3D%3DR%2BinCPF4KwXJ3b2zTDPGatftRO6mCw59Zf9g5zAPRw%40mail.gmail.com.

[Tobia...@gmx.de]

What are good criteria for evaluating different ways to install Python?

• Reliability

• Installation speed

• Disk space used after installation

• Ease of use for end users

• Suitability for distributions

• Suitability for the macOS app (listed separately due to its unique packaging and distribution requirements)

Did I miss something?

For the first two points, using a precompiled Python (like the one provided by uv) is clearly faster and more reliable than building from source. The uv installation is heavily optimized, though it's unclear to me whether it's smaller or larger than a source build. It would be helpful if Marc could share the size of the Python installation on macOS to compare with William’s numbers for uv.

From a user-experience perspective, it's slightly easier to run a single global make command that installs Python as part of the python-spkg. That said, the python-spkg doesn't necessarily have to build Python from source - it could still use a precompiled version (say via uv) under the hood.

“Normal” Linux distributions typically include their own Python, so they don’t depend on Sage’s Python packaging.

I don’t have the expertise to speak confidently about macOS packaging, but my impression is that tools like PyOxidizer use similar prebuilt Pythons and are capable of producing signed and notarized apps. It would be great if Marc (or others familiar with the macOS side) could explain how other Python projects embed Python to generate signed applications; and why it's so important for the sage macos app to build from source.

[Trevor Karn]

• Reliability

• Installation speed

• Disk space used after installation

• Ease of use for end users

• Suitability for distributions

• Suitability for the macOS app (listed separately due to its unique packaging and distribution requirements)

Also - to Marc's point - ease of maintenance for developers. Maybe this is encapsulated in "suitability"... Definitely not the highest priority - users should be our focus - but this thread demonstrates it needs to be on the list.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/c56945d8-3008-4163-bd61-af3759188ff5n%40googlegroups.com.

[Nathan Dunfield]

Dima,

I looked through the logs, do you agree the following is a rough summary of the issue in this case?

The user building Sage from source uses a package manager that installs software in /opt/homebrew/.  They had some components of Sage installed in /opt/homebrew but fewer than we recommend.  They then had compile issues with gsl and python, both of which can be provided by homebrew and are on our recommended list.

Also, am I correct that the error specific to Python was:

1. The Sage configure process detected OpenSSL in homebrew so didn't build it.

2. Python's build process only looks in /usr, /usr/local and SAGE_LOCAL for dependencies, so couldn't find OpenSSL.

Thanks,

Nathan

[Nils Bruin]

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

[Dima Pasechnik]

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

[William Stein]

On Sun, Apr 6, 2025 at 11:40 AM Dima Pasechnik <dim...@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+...@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)

[Marc Culler]

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.

[Marc Culler]

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

[Dima Pasechnik]

On Sun, Apr 6, 2025 at 6:07 PM Marc Culler <marc....@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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/6bb01f94-9ba5-46f2-93e1-6332231cdea8n%40googlegroups.com.

[Nathan Dunfield]

1) Having sagemath detect python version requirements and build its own if not acceptable version is found leads to increased support requests.

[...] 

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.

Building on this idea, I wonder if there should be a mechanism along the lines of:

When compiling on macOS and homebrew is present, check if all the recommended homebrew packages are present and only proceed if they are or the person provides the flag "--proceed-at-own-risk". 

In the particular case that Dima highlighted, Python was actually the second spkg not to build; the first was gsl which is one of the recommended homebrew packages.

Best,

Nathan

P.S. I'm assuming that the issue compiling Python are specific to macOS and that OS's failure to provide openssl as a system library.  Dima please correct me if that you are also seeing Python compilation errors on Linux.

[Nathan Dunfield]

On Monday, April 7, 2025 at 1:19:45 AM UTC-5 Dima wrote:

Homebrew, uv, etc provide single-arch Python3 just fine.

I believe that Homebrew wouldn't work because of the issue with rpaths that Marc hints at earlier in his message -- in particular the paths are baked in as /opt/homebrew/* and will not survive relocation.  The "uv" installer can install in varying locations, but I'm not sure the result is relocatable.  In any event, provided one tells configure where to find openssl, Python is easy and robust to build on macOS in my experience, so using uv would just complicate matters from the perspective of building the self-contained macOS app.

Best,

Nathan 

 

[William Stein]

> I believe that Homebrew wouldn't work because of the issue with rpaths that Marc hints at earlier in his message -- in particular the paths are baked in as /opt/homebrew/* and will not survive relocation. The "uv" installer can install in varying locations, but I'm not sure the result is relocatable.

The result of using the uv installer is relocatable. (It also links
in ssl and pretty much everything, of course.)

bash-3.2$ du -sch
/Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/*
76K /Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/bin
2.3M /Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/include
45M /Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/lib
24K /Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/share
48M total
bash-3.2$ /Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/bin/python
Python 3.13.2 (main, Mar 17 2025, 21:26:38) [Clang 20.1.0 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
bash-3.2$ mv /Users/williamstein/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/
/tmp/uv-python
bash-3.2$ /tmp/uv-python/bin/python
Python 3.13.2 (main, Mar 17 2025, 21:26:38) [Clang 20.1.0 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>>
bash-3.2$ du -sch /tmp/uv-python
48M /tmp/uv-python
48M total

The developers of uv may have put more effort into making Python easy
to distribute than we have. They want
distribution and packaging to be more modern, fast and reliable, like
it is with Rust and some other ecosystems.

William


https://github.com/astral-sh/python-build-standalone

[Dima Pasechnik]

On 7 April 2025 07:48:37 GMT-05:00, Nathan Dunfield <nat...@dunfield.info> wrote:
>
>
>1) Having sagemath detect python version requirements and build its own if
>not acceptable version is found leads to increased support requests.
>
>[...]
>
>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.
>
>
>Building on this idea, I wonder if there should be a mechanism along the
>lines of:
>

>When compiling on macOS and homebrew is present, check if *all* the recommended
>homebrew packages
><https://doc.sagemath.org/html/en/installation/source.html#macos-package-installation> are

>present and only proceed if they are or the person provides the flag
>"--proceed-at-own-risk".
>
>In the particular case that Dima highlighted, Python was actually the
>second spkg not to build; the first was gsl which is one of the recommended
>homebrew packages.
>
>Best,
>
>Nathan
>
>P.S. I'm assuming that the issue compiling Python are specific to macOS and
>that OS's failure to provide openssl as a system library. Dima please
>correct me if that you are also seeing Python compilation errors on Linux.

We do see similar problems on Linux being run in WSL. It's probably due to WSL defaulting to an old Ubuntu version, on which you need to jump extra hoops to install modern Python.

Also, people try native builds on HPC clusters, which typically run weird old versions of Linux, where the only working way out I know is to use Conda.

Dima



>

[Marc Culler]

On Mon, Apr 7, 2025 at 10:03 AM Dima Pasechnik <dim...@gmail.com> wrote:

We do see similar problems on Linux being run in WSL. It's probably due to WSL defaulting to an old Ubuntu version, on which you need to jump extra hoops to install modern Python.

The most recent such issue that I could find involved someone using Ubuntu 24.04 on WSL.  That is hardly an old Ubuntu version.

- Marc

[Marc Culler]

As this discussion tries to wander off into a new discussion about the uv project, I will attempt to bring it back on topic.

The point is this:  Currently, to build the macOS binary, we first build sage in a completely standard way.  The only customization we need to do is to set up the configure options. After that completely standard build we construct the app from the sage directory.  That involves removing some unneeded things, making some modifications and making Sage (not just python, Sage) relocatable and self-contained.  But the starting point is just a completely standard build of Sage.

If the Python spkg were removed we would no longer be able to start from a standard build of Sage.  That first step becomes more complicated and, more importantly, non-standard.  I am certain that we would be able to come up with something that works.  That is not the issue.  The issue is that we will have hacked the Sage build system to do that.  People who are making changes that affect the Sage build system are likely to make changes which break our hack, whatever it turns out to be, because they will have no idea what the hack is and no obligation to ensure that it continues to work.  With the current setup, starting from a completely standard Sage build process, there is virtually no chance that someone will break our build process for the macOS app.

- Marc

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CACLE5GCqfaOgUxaQo%3DOoLPfj2YHDqYOu-0bt4UicvcBwJANbgg%40mail.gmail.com.

[David Lowry-Duda]

On 15:11 Sun 06 Apr 2025, Marc Culler wrote:
>> 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.

Maybe I'm misinterpreting, but we already have --with-system-python3 that defaults to "yes", right? Is this different than the proposed --install_own_python option?

- DLD

[Nils Bruin]

On Monday, 7 April 2025 at 09:17:18 UTC-7 David Lowry-Duda wrote:

Maybe I'm misinterpreting, but we already have --with-system-python3 that defaults to "yes", right? Is this different than the proposed --install_own_python option?

I would expect that the flag *prefers* a system python that meets the set version requirements, but will proceed to try and build python3 if it cannot find a suitable version. The proposed change in behaviour would be to default to raising an error and halting the build attempt because in most situations, the absence of a suitable python3 is indicative of a deficient building environment anyway.

Apparently users in that situations are generally better off going with conda to ensure the prerequisites are in place. That's not unreasonable, given that conda was developed exactly to provide people with a scientific computing  environment.  I can see why the architecture of the MacOS app is not well-suited for that approach, given that it should be self-contained.

[Dima Pasechnik]

On Monday, April 7, 2025 at 10:59:40 AM UTC-5 marc....@gmail.com wrote:

As this discussion tries to wander off into a new discussion about the uv project, I will attempt to bring it back on topic.

The point is this:  Currently, to build the macOS binary, we first build sage in a completely standard way.  The only customization we need to do is to set up the configure options. After that completely standard build we construct the app from the sage directory.  That involves removing some unneeded things, making some modifications and making Sage (not just python, Sage) relocatable and self-contained.  But the starting point is just a completely standard build of Sage.

It's not standard - no-one nowadays builds Sage's Python, not even CI is doing this.

This is the point I already made.
You are the sole users of this semi-broken feature.

Dima
 

[Dima Pasechnik]

It is likely the case, but this is exactly my point - we don't want to spend our and other people time on solving a problem no other python package out there is doing - building Python from source.

I am all ears as far as needs of building macOS app is concerned, I am willing to spend my time on helping you out, but I am dead against keeping Python spkg in Sage.

Dima

[Marc Culler]

On Mon, Apr 7, 2025 at 3:25 PM Dima Pasechnik wrote:

It's not standard - no-one nowadays builds Sage's Python, not even CI is doing this.

This is the point I already made.
You are the sole users of this semi-broken feature.

Well, it is a feature that is available by just setting one configure option, and we have used the feature with Sage 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5 and 10.6 without encountering a single failure of the python3 spkg.  Moreover you have not been able to produce an example of a build that failed because of the python3 spkg.  Your macOS example had actually failed on a different spkg that gets built before the python3 spkg, and the cause was a misconfigured homebrew installation.  Your Ubuntu 24.04 on WSL example failed in the same way when the system python 3.12 was installed and available.  So while I do observe that a lot of your time is being spent debugging Sage build failures for users, and I certainly appreciate that effort, there seems to be no evidence at all that removing the python3 spkg will reduce the amount of that time.  Moreover, Nils' proposal would prevent anyone from accidentally using the python3 spkg, so that should ensure that none of the build failures reported to the Sage project would be failures of the python3 spkg.

- Marc

[Dima Pasechnik]

On Mon, Apr 7, 2025 at 5:12 PM Marc Culler <marc....@gmail.com> wrote:
>
>
>
> On Mon, Apr 7, 2025 at 3:25 PM Dima Pasechnik wrote:
>>
>>
>> It's not standard - no-one nowadays builds Sage's Python, not even CI is doing this.
>>
>> This is the point I already made.
>> You are the sole users of this semi-broken feature.
>
>
> Well, it is a feature that is available by just setting one configure option, and we have used the feature with Sage 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5 and 10.6 without encountering a single failure of the python3 spkg.

That's experience of the macOS app devs group, on macOS. Hardly a
representative sampling. I could also say that building GAP from
source is totally trivial and always works - I'm doing this for the
last 30 years, therefore I know better!

> Moreover you have not been able to produce an example of a build that failed because of the python3 spkg.

Marc, there are currently several support cases running, which would
not be there if the ability to build Python/Python toolchain from
source was absent in Sage.

> Your macOS example had actually failed on a different spkg that gets built before the python3 spkg, and the cause was a misconfigured homebrew installation. Your Ubuntu 24.04 on WSL example failed in the same way when the system python 3.12 was installed and available.

Well, not really. E.g.
https://groups.google.com/g/sage-devel/c/6wYRLYsfbG4 is talking about
failures of building setuptools.
But we already require setuptools to be available in the acceptable
python3 from the system. That is to say, we can remove setuptools spkg
as soon as we remove python3 spkg.
Once again, let us just get out of business of vendoring Python and
Python build toolchain, for it brings everybody nothing but pain,
toil, and suffering. Hopefully we can get to work on enhancing maths
capabilities of Sage instead...

> So while I do observe that a lot of your time is being spent debugging Sage build failures for users, and I certainly appreciate that effort, there seems to be no evidence at all that removing the python3 spkg will reduce the amount of that time. Moreover, Nils' proposal would prevent anyone from accidentally using the python3 spkg, so that should ensure that none of the build failures reported to the Sage project would be failures of the python3 spkg.

Obviously, if users use a ready toolchain we don't have to help them
build one from source. Win-win situation, for them
and for us.
Besides, Nils' proposal would mean to introduce an entirely new kind
of Sage package, and we already have far too many of these:
standard, optional, experimental, dummy, base, pre-req, etc. are
already there. Nils' proposal doesn't fit any of these.
Instead of reducing the complexity of the spaghetti monster this
proposes threading even more noodle through.

Dima
>
> - Marc
>
> --

> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CALcZXRGQ7p3QPQpkzo3a-ZAeZaMiuU3mH0_igFGxmUY6E39Jsw%40mail.gmail.com.

[Marc Culler]

On Monday, April 7, 2025 at 11:48:15 PM UTC-5 Dima wrote:

Besides, Nils' proposal would mean to introduce an entirely new kind  of Sage package, 

No, it wouldn't.  It would make a small change to how one existing configure option is handled by the configure script.

- Marc

[Dima Pasechnik]

No, this won't fly. This is going to break the already fragile logic
behind package types.
Standard packages cannot be optionally installed, so it can't stay
standard. Optional packages probably cannot appear in toolchain.
Etc etc. You really want an entirely new package type; you have a
single-consumer issue, and you want everyone to run circles around you
so that
you yourself can do as little extra work as possible.
Get us an Apple or other grant to work on this, then we can talk about it.
And this is going to be a major break on badly needed restructuring of
Sage the distro.

>
> - Marc
>
> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/2a5b3ca8-2ea6-42f2-8255-8f6ae9a72136n%40googlegroups.com.

[Nils Bruin]

On Wednesday, 9 April 2025 at 12:15:07 UTC-7 dim...@gmail.com wrote:

No, this won't fly. This is going to break the already fragile logic
behind package types.
Standard packages cannot be optionally installed, so it can't stay
standard. Optional packages probably cannot appear in toolchain.

Presently python3 is a standard package, right? And most of the time the packages "succeeds" by not installing anything (because prerequisites are sufficient to provide what is wanted). Standard packages can also fail if hard prereqs are not met. We can have a standard package python3 that is simply a stand-in for ensuring that a sufficient python is provided. It looks like there is a particular scenario where python3 would behave differently, by actually installing python3 -- namely for building the MacOS app.

It sounds to me that Marc is worried that satisfying the python3 requirement for the MacOS app is going to be fragile if it's not done through the standard package route that has been in place since the start of sage. That's more a confidence/trust issue than a technical issue. Hence, providing a smoother transition path may inspire more confidence in the participants.

Your stated primary concern about the python3 package was that its attempt to build mask other prerequisite deficiencies in the build environment. Having a standard python3 package that by default only checks for the availability of a sufficient python but that can still build python3 if people really want would address your primary concern. So that should count as progress for you.

At the same time, the concession that python3.spkg *can* still provide python if really wanted helps Marc see that the MacOS app build is taken seriously. I would expect it's a major delivery platform of sagemath functionality to users, so it should be taken seriously.

Quite frankly, things like conda and uv are great initiatives and it would be great for sage to work nice with them. Conda is getting quite mature and has a wide user base, so transitioning to depending on conda may be a reasonable  choice. Even if something strange happens to the organization behind Conda (those things tend to happen with open source initiatives on a fairly regular basis), I think at this point we can be fairly confident that it would get forked and remain reasonably supported. With "uv", on the other hand, I don't think there's the track record yet to convert to being dependent on it without alternatives.

Slow transitions in build architecture decisions in mature projects are a feature, not a bug.

[Trevor Karn]

At the same time, the concession that python3.spkg *can* still provide python if really wanted helps Marc see that the MacOS app build is taken seriously. I would expect it's a major delivery platform of sagemath functionality to users, so it should be taken seriously.

Anecdotally in my department, it seems at least as many people use the MacOS build as build from source. so +1 to this.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/-ASHfAXqVYo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/c9f1ff09-5e5c-4b48-b8c1-cc636dc05d3an%40googlegroups.com.

[William Stein]

> On Wed, Apr 9, 2025 at 2:37 PM Nils Bruin <nbr...@sfu.ca> wrote:
>> Quite frankly, things like conda and uv are great initiatives and it would be great for sage to work nice with them. Conda is getting quite mature and has a wide user base, so transitioning to depending on conda may be a reasonable choice. Even if something strange happens to the organization behind Conda (those things tend to happen with open source initiatives on a fairly regular basis), I think at this point we can be fairly confident that it would get forked and remain reasonably supported. With "uv", on the other hand, I don't think there's the track record yet to convert to being dependent on it without alternatives.

You wrote "...convert to being dependent on it without alternatives."
but I didn't have the impression that anybody is proposing that Sage
be *dependent* on Conda or uv. Instead, the proposal is that people
install Python somehow; conda and uv are merely examples to show that
in 2025 there are extremely good ways to install Python.

NOTE: uv is just providing binaries from another project that has been
around for a longer time, and the uv developers are also now
contributing to that project.

[dim...@gmail.com]

On Wed, Apr 09, 2025 at 12:36:59PM -0700, Nils Bruin wrote:
> On Wednesday, 9 April 2025 at 12:15:07 UTC-7 dim...@gmail.com wrote:
>
> >No, this won't fly. This is going to break the already fragile logic
> >behind package types.
> >Standard packages cannot be optionally installed, so it can't stay
> >standard. Optional packages probably cannot appear in toolchain.
>
>
> Presently python3 is a standard package, right? And most of the time the
> packages "succeeds" by not installing anything (because prerequisites are
> sufficient to provide what is wanted). Standard packages can also fail if
> hard prereqs are not met. We can have a standard package python3 that is
> simply a stand-in for ensuring that a sufficient python is provided. It
> looks like there is a particular scenario where python3 would behave
> differently, by actually installing python3 -- namely for building the
> MacOS app.

As I already explained, it's quite a stretch by Sage's standards to call
python3 package standard. Because it is not tested enough;
because few months into release, the supposedly stable Sage release is
often not installable, not the least due to rapidly aging Python
toolchain.

As it has been shown here too, already, it's really a very little effort
for macOS app project to switch to an external python toolchain,
they are just stubbonly unwilling to consider this option, saying things
like "don't turn this thread into uv thread". But why not?
They are the only known to us consumer of python3 spkg who depend on it
in a somewhat nontrivial way. I don't want to go into merits of the
macOS app, but it's a highly non-standard by modern Python standards
thing which does not bring to users full functionality of Sage, and ties
them up to a shifty expensive platform.

>
> It sounds to me that Marc is worried that satisfying the python3
> requirement for the MacOS app is going to be fragile if it's not done
> through the standard package route that has been in place since the start
> of sage.

The times where everything, including python, is vendored by Sage, are
long gone. Let's drop the ballast which pulls the project down, and
concentrate on Sage{\bf MATH}, please.
python3 spkg is fragile already, it's a ballast.

Sagelib is teeming with difficult bugs, yet we waste time here.

Do you know how long supposedly standard package brial is essentially broken?
Do you know how many leaks we have in Singular and GAP interfaces?
Do you know that linbox, fflas_ffpack and givaro increasingly look like abandonware?
Do you know that with each new release of Maxima the number of bugs they
cause in Sage doesn't look like it goes down?

Please look at the bigger picture. Let's assign proper priorities
to tasks ahead. Vendoring python with its toolchain is certainly much
lower priority than the above.

> That's more a confidence/trust issue than a technical issue.
> Hence, providing a smoother transition path may inspire more confidence in
> the participants.
>
> Your stated primary concern about the python3 package was that its attempt
> to build mask other prerequisite deficiencies in the build environment.
> Having a standard python3 package that by default only checks for the
> availability of a sufficient python but that can still build python3 if
> people really want would address your primary concern. So that should count
> as progress for you.

No, not really. Getting rid of python3 spkg is just the 1st step towards un-vendoring.
Vendoring python and its toolchain should be left to Python experts.
These things should be external to the specialist maths software project like SageMath.
As long as they are a part of the project, they are ballast making things more
complicated than needed.

>
> At the same time, the concession that python3.spkg *can* still provide
> python if really wanted helps Marc see that the MacOS app build is taken
> seriously. I would expect it's a major delivery platform of sagemath
> functionality to users, so it should be taken seriously.
>
> Quite frankly, things like conda and uv are great initiatives and it would
> be great for sage to work nice with them. Conda is getting quite mature and
> has a wide user base, so transitioning to depending on conda may be a
> reasonable choice. Even if something strange happens to the organization
> behind Conda (those things tend to happen with open source initiatives on a
> fairly regular basis), I think at this point we can be fairly confident
> that it would get forked and remain reasonably supported. With "uv", on the
> other hand, I don't think there's the track record yet to convert to being
> dependent on it without alternatives.

One can more or less do with pip most things you do with uv.
It's just slower, and does not come with an easy to manage built in
venvs.
I won't be worried about uv disappearing, as it's an easy switch to more
usual, older tools.
I would be more worried about going into exclusively Conda direction.
Conda (Conda-forge) is much heavier, as it comes with its own full toolchain, which is
controlled by Anaconda Inc.

>
> Slow transitions in build architecture decisions in mature projects are a
> feature, not a bug.

We are already late by about 5 or 6 years.
Let's speed up, before we're sunk into obscurity, by Julia/OSCAR, for
instance.

Dima

[Nils Bruin]

On Wednesday, 9 April 2025 at 16:44:31 UTC-7 dim...@gmail.com wrote:

As I already explained, it's quite a stretch by Sage's standards to call
python3 package standard. Because it is not tested enough;
because few months into release, the supposedly stable Sage release is
often not installable, not the least due to rapidly aging Python
toolchain.

Are you saying that python source distributions bitrot particularly quickly? Is there something particular about python that breaks their source distributions so quickly? If that's the case, I think that's concerning in itself. It should be possible to build a python source distribution that is a few years old without a problem, right? Its prerequisites shouldn't be breaking their APIs on such short timescales.

 

[Nils Bruin]

On Monday, 7 April 2025 at 08:59:40 UTC-7 marc....@gmail.com wrote:

If the Python spkg were removed we would no longer be able to start from a standard build of Sage.

Can you explain what the non-standard part would be and why you are concerned it would be more fragile on the side of Sage? To me it looks you would start out with building python much in the same way as how it now gets built by sage's python3 package and then in the ensuing environment you would end up building sage in a completely standard way, with the python requirement satisfied by the python build you have just completed. Given that the python build would complete *before* you even get started on building sage, I would expect that this doesn't affect the fragility of the sage build at all. Are you worried that sage would have trouble recognizing the python build as valid for its purposes?

If anything, I'd expect that if sage would not be providing its own python package, it would be forced to be more tolerant on what python to accept. So I can see how giving away full control of python could make *sage* more fragile, but at the same time we are already relying on externally provided pythons in many cases and that doesn't seem to cause huge problems.

[Marc Culler]

On Wed, Apr 9, 2025 at 8:07 PM Nils Bruin <nbr...@sfu.ca> wrote:

On Monday, 7 April 2025 at 08:59:40 UTC-7 marc....@gmail.com wrote:

If the Python spkg were removed we would no longer be able to start from a standard build of Sage.

Can you explain what the non-standard part would be

William says "the proposal is that people install Python somehow" which means that there would be no specific supported way of doing it.

and why you are concerned it would be more fragile on the side of Sage?

In order to be usable in the app, the python would need to be installed inside of the app.  When Sage is built, a directory named local/var/lib/sage/venv-python3.X.Y is created, along with a symlink to that directory named venv which is at the top level, adjacent to the "local" directory.  Despite the name, the venv directory is not a venv, by Python's definition, because it has no pyvenv.cfg file inside.  So it really is a python prefix directory, which Sage suggests is a venv.  And when Sage builds python it uses that directory as the prefix.  When you "install" a "system python" in Sage, it also uses the venv directory, but  in a different way.  There are many ways to populate the venv.  One way would be to put symlinks inside so, for example, venv/bin/python3.12 might be a symlink to the homebrew python executable and venv/lib/python3.12 might be a symlink to the homebrew python library directory.  Another way would be to copy the homebrew files into the venv directory.  The first method is totally useless for building the app.  The symlinks would work for running sage on the computer where sage was built, but not on a different computer without homebrew or without the same version of homebrew's python.  Moreover, Apple will not notarize an app containing symlinks that point outside of the app bundle, whether or not they might work on a given system.  I don't actually know whether a pyvenv.cfg file gets created when using a "system python" but I suspect not.  And I don't know how the venv gets populated when a "system python" is used.  These would be things I would have to discover by trial and error and adjust for.

To me, when the "standard" is "people install Python somehow" there is no commitment whatsoever about any of the crucial details of how the "system python" is actually being "installed" inside of Sage.  Therefore there is no expectation of consistency from one Sage release to the next and basically I would have to count on having it change our build system all the time.

Leaving the spkg in place would mean that there is an expectation of consistency.  In particular, if the Sage_macOS project were really the one and only user of the spkg for each Sage release then there would be no motivation for changing it.  So it would continue to work.  I would be willing to update the python version in the spkg and make sure it works (for us, the only user).  But even that would have an expectation of failure because other aspects of the build system might change in ways which would force a change to the layout of the spkg..  We probably would not know about these until we ran into the failure.

 

To me it looks you would start out with building python much in the same way as how it now gets built by sage's python3 package and then in the ensuing environment you would end up building sage in a completely standard way, with the python requirement satisfied by the python build you have just completed.

I see no reason to expect that if I have a build of python somewhere on my system, Sage would be able to use it.  The "people install Python somehow" standard does not specify what such a python would need to look like.  At the most basic level, there are two different ways of building Python on macOS.  There are "Framework" builds and "prefix" builds.  Which of those meet the requirements of the "people install Python somehow" standard?  (I would probably prefer the "Framework" build since I use a Framework for sage itself.)  In any case the crucial question is: how will the venv directory be populated by the Sage build system?  And how often will that change?  When will someone decide to add a symlink somewhere in the venv, because it works fine on the build system, and thereby break the process of making sage self-contained and relocatable.

Given that the python build would complete *before* you even get started on building sage, I would expect that this doesn't affect the fragility of the sage build at all.

Probably not on the build system.  But the app needs to work on *any* system.

Are you worried that sage would have trouble recognizing the python build as valid for its purposes?

Since there is no proposal for specifying what properties such a python build must have in order for sage to recognize it, that is something to worry about, yes. And I outlined some details of those worries above.  The details of how the venv gets populated make a big difference.  To make Sage self-contained and relocatable it is necessary to control the shebang line in every script and the rpath in every executable (which usually means editing the absolute library path to make it relative and adding an rpath).

 

If anything, I'd expect that if sage would not be providing its own python package, it would be forced to be more tolerant on what python to accept.

I wouldn't expect that.  I would expect maximum intolerance - you must use conda or you must use homebrew.  (And you must agree, counter to all experience, that building python is an extremely difficult task that must be left to python-building-experts.)  I guess the good part of maximum intolerance is that it is consistent, at some level. Although there is no reason to expect the python-building-experts to be consistent between releases of their own products.

So I can see how giving away full control of python could make *sage* more fragile, but at the same time we are already relying on externally provided pythons in many cases and that doesn't seem to cause huge problems.

As I have tried to indicate, it is more about the details of how an installation of python somewhere on the system will get used to populate the venv directory within Sage.  It will also be important to know when in the build process that happens.  (If changes are needed to that python installation, is it necessary to interrupt the build process to make the changes?  Is that even possible when building in parallel?)  It is also important for the venv construction to be done consistently from one sage release to the next,

to avoid having to do a trial and error redesign of our build system for every release of Sage..

- Marc

[Dima Pasechnik]

On 9 April 2025 18:54:13 GMT-05:00, Nils Bruin <nbr...@sfu.ca> wrote:
>On Wednesday, 9 April 2025 at 16:44:31 UTC-7 dim...@gmail.com wrote:
>
>As I already explained, it's quite a stretch by Sage's standards to call
>python3 package standard. Because it is not tested enough;
>because few months into release, the supposedly stable Sage release is
>often not installable, not the least due to rapidly aging Python
>toolchain.
>
>Are you saying that python source distributions bitrot particularly
>quickly? Is there something particular about python that breaks their
>source distributions so quickly? If that's the case, I think that's
>concerning in itself.

it's not unusual for some "move fast and break things" OS vendors to change APIs in incompatible ways, update toolchains in incompatible ways, e.g. Apple does it quite often, as we learned over the years. And do not forget rolling release OSes.

python (minor) releases come up every 2 months, sometimes every month. I gather it's in response to the OS updates, in part.

Our releases are less frequent, and we often don't check that Sage works on such and such betas and pre-releases.

> It should be possible to build a python source
>distribution that is a few years old without a problem, right?

no, not really. On some Linux OSes like Debian, some open-source BSDs perhaps, on others much less so.

E.g. Apple's XCode update released a short while ago has broken Sage 10.6. (as the C++ compiler got a version bump).

Vendors of maths soft should not want to come close to components which closely interact with the OS, such as compilers and interpreters, unless they just cannot avoid it. In case of Python it's surely beneficial not to come close to it, as Python's vendor does a very good job in doing ptompt updates, a surely a much better job than our attempts to vendor them.
Same applies to compilers.

> Its
>prerequisites shouldn't be breaking their APIs on such short timescales.

Tell this to Apple, RedHat (i.e. IBM). :-)

Dima

>
>

[Nasser M. Abbasi]

Hello;

Has anyone considered making sage as container? This will eliminate all these issues being discussed here, I would think.

Google AI says this:

"Container-based software delivery packages applications and their dependencies 

into lightweight, isolated environments called containers, enabling consistent and 

reliable deployment across different computing environments"

"Benefits of Containerization:

• Portability: Containers can run consistently across different environments, from development to production, without compatibility issues. 
• Efficiency: Containers are lightweight and resource-efficient, requiring fewer resources than virtual machines. 
• Scalability: Containers can be easily scaled up or down, making them ideal for modern, cloud-native applications. 
• Consistency: Containerized applications run the same way regardless of the underlying infrastructure, ensuring consistency across deployments."

I do not know if this can work for sage, but it seems to me, sagemath being a very complicated and advanced
software with many parts with many dependencies, a container type delivery will be perfect solution.

--Nasser

[William Stein]

I regularly build proper multiarch (so x86 and arm) Sage Docker
containers, e.g.,

https://hub.docker.com/repository/docker/sagemathinc/sagemath/general

https://hub.docker.com/orgs/sagemathinc/repositories

-- William

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/03351ca7-e41b-46b8-beea-0ab36d510a79n%40googlegroups.com.



--
William (http://wstein.org)

[Dima Pasechnik]

On Wed, Apr 9, 2025 at 10:21 PM Marc Culler <marc....@gmail.com> wrote:
>
> On Wed, Apr 9, 2025 at 8:07 PM Nils Bruin <nbr...@sfu.ca> wrote:
>>
>> On Monday, 7 April 2025 at 08:59:40 UTC-7 marc....@gmail.com wrote:
>>
>> If the Python spkg were removed we would no longer be able to start from a standard build of Sage.
>>
>> Can you explain what the non-standard part would be
>
>
> William says "the proposal is that people install Python somehow" which means that there would be no specific supported way of doing it.
>
>> and why you are concerned it would be more fragile on the side of Sage?
>
>
> In order to be usable in the app, the python would need to be installed inside of the app. When Sage is built, a directory named local/var/lib/sage/venv-python3.X.Y is created, along with a symlink to that directory named venv which is at the top level, adjacent to the "local" directory. Despite the name, the venv directory is not a venv, by Python's definition, because it has no pyvenv.cfg file inside. So it really is a python prefix directory, which Sage suggests is a venv. And when Sage builds python it uses that directory as the prefix. When you "install" a "system python" in Sage, it also uses the venv directory, but in a different way. There are many ways to populate the venv. One way would be to put symlinks inside so, for example, venv/bin/python3.12 might be a symlink to the homebrew python executable and venv/lib/python3.12 might be a symlink to the homebrew python library directory. Another way would be to copy the homebrew files into the venv directory. The first method is totally useless for building the app. The symlinks would work for running sage on the computer where sage was built, but not on a different computer without homebrew or without the same version of homebrew's python. Moreover, Apple will not notarize an app containing symlinks that point outside of the app bundle, whether or not they might work on a given system. I don't actually know whether a pyvenv.cfg file gets created when using a "system python" but I suspect not. And I don't know how the venv gets populated when a "system python" is used. These would be things I would have to discover by trial and error and adjust for.
>
> To me, when the "standard" is "people install Python somehow" there is no commitment whatsoever about any of the crucial details of how the "system python" is actually being "installed" inside of Sage.

As a matter of fact, with the recently added meson build configs, one
can finally build sagelib as an absolutely normal Python package,
by calling "pip install ." in an already created standard venv.
So no more hacked Sage venv, just a normal Python venv. It cannot get
any better than this.
That's obviously assuming that all non-Python Sage dependencies are
already installed.

So can just use this build method and stop worrying about Sage venv.
As a matter of fact, I tested it on macOS today, to proceed with
fixing Sage build on the latest XCode.
I have an Intel MacBook with a full Sage build environment installed
in /usr/local.
It's a mix of Homebrew, Homebrew taps by Macaulay2 people:
https://github.com/Macaulay2/homebrew-tap
and hand-installed stuff such as m4ri and m4rie (I'm planning to fix a
few Homebrew formulas to facilitate this).
I had in fact to update few Homebrew formulae for Macaulay2 taps, as
they stopped working with the new XCode.
see https://github.com/Macaulay2/homebrew-tap/pull/270.
(that's of course a personal choice, some people might want a full
hand-built setup).

Just to get a taste of uv, I tried to do a build with a Python 3.12.9,
and a venv, provided by uv.
And it works, and it's 5-10 times faster than pip on various tasks.

> Therefore there is no expectation of consistency from one Sage release to the next and basically I would have to count on having it change our build system all the time.

This is not so any more - we have more or less converged to the point
where you can build sagelib in a standard Python way.
It remains to fix docbuild, in fact, but that should not be a big
problem, I gather.

>
> Leaving the spkg in place would mean that there is an expectation of consistency. In particular, if the Sage_macOS project were really the one and only user of the spkg for each Sage release then there would be no motivation for changing it. So it would continue to work. I would be willing to update the python version in the spkg and make sure it works (for us, the only user). But even that would have an expectation of failure because other aspects of the build system might change in ways which would force a change to the layout of the spkg.. We probably would not know about these until we ran into the failure.
>
>>
>> To me it looks you would start out with building python much in the same way as how it now gets built by sage's python3 package and then in the ensuing environment you would end up building sage in a completely standard way, with the python requirement satisfied by the python build you have just completed.
>
>
> I see no reason to expect that if I have a build of python somewhere on my system, Sage would be able to use it. The "people install Python somehow" standard does not specify what such a python would need to look like. At the most basic level, there are two different ways of building Python on macOS. There are "Framework" builds and "prefix" builds. Which of those meet the requirements of the "people install Python somehow" standard? (I would probably prefer the "Framework" build since I use a Framework for sage itself.) In any case the crucial question is: how will the venv directory be populated by the Sage build system? And how often will that change? When will someone decide to add a symlink somewhere in the venv, because it works fine on the build system, and thereby break the process of making sage self-contained and relocatable.
>

You can just put *any* python build of your choice and its venv
anywhere on the system, or let a tool like uv do it for you,
so that all the PATHs etc are set, etc.

>> Given that the python build would complete *before* you even get started on building sage, I would expect that this doesn't affect the fragility of the sage build at all.
>
>
> Probably not on the build system. But the app needs to work on *any* system.
>
>> Are you worried that sage would have trouble recognizing the python build as valid for its purposes?
>

No. Because sagelib (with meson build) is already a proper Python
package, which should just shut up and get installed as a Python
package of a Python. :-)
(And the rest is just a semi-optional environment coming on top of
sagelib, pretty much orthogonal to what's in the macOS app)

Let me stop here, as hopefully this point alleviates all of the Marc concerns.

Dima

>
> Since there is no proposal for specifying what properties such a python build must have in order for sage to recognize it, that is something to worry about, yes. And I outlined some details of those worries above. The details of how the venv gets populated make a big difference. To make Sage self-contained and relocatable it is necessary to control the shebang line in every script and the rpath in every executable (which usually means editing the absolute library path to make it relative and adding an rpath).
>
>>
>> If anything, I'd expect that if sage would not be providing its own python package, it would be forced to be more tolerant on what python to accept.
>
>
> I wouldn't expect that. I would expect maximum intolerance - you must use conda or you must use homebrew. (And you must agree, counter to all experience, that building python is an extremely difficult task that must be left to python-building-experts.) I guess the good part of maximum intolerance is that it is consistent, at some level. Although there is no reason to expect the python-building-experts to be consistent between releases of their own products.
>
>> So I can see how giving away full control of python could make *sage* more fragile, but at the same time we are already relying on externally provided pythons in many cases and that doesn't seem to cause huge problems.
>
>
> As I have tried to indicate, it is more about the details of how an installation of python somewhere on the system will get used to populate the venv directory within Sage. It will also be important to know when in the build process that happens. (If changes are needed to that python installation, is it necessary to interrupt the build process to make the changes? Is that even possible when building in parallel?) It is also important for the venv construction to be done consistently from one sage release to the next,
> to avoid having to do a trial and error redesign of our build system for every release of Sage..
>
> - Marc
>

> --

> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CALcZXRF9t3PtcxJ_6FPba%3D0ZSzh08JdZ%2BdC0dw7qm1ZpHLXbew%40mail.gmail.com.

[Nathan Dunfield]

On Thursday, April 10, 2025 at 12:07:03 AM UTC-5 Dima wrote:

> Probably not on the build system. But the app needs to work on *any* system.
>
>> Are you worried that sage would have trouble recognizing the python build as valid for its purposes?
>
No. Because sagelib (with meson build) is already a proper Python
package, which should just shut up and get installed as a Python
package of a Python. :-)
(And the rest is just a semi-optional environment coming on top of
sagelib, pretty much orthogonal to what's in the macOS app)

To me, a "proper Python package" is something I can install with "random-python -m pip install blah" that pulls a binary wheel off PyPI that just works.  If we're getting close to being able to do that, which would absolutely amazing, then why not wait until that's done so we can ditch sage-the-distribution completely?

While I understand the dislike for sage-the-distribution, removing Python (and perhaps some other collection of spkgs) creates sage-the-kinda-distribution which is less useful and, I suspect, even more fragile.

Best,

Nathan 

 

[Nathan Dunfield]

On Wednesday, April 9, 2025 at 2:58:51 PM UTC-5 Trevor Karn wrote:

At the same time, the concession that python3.spkg *can* still provide python if really wanted helps Marc see that the MacOS app build is taken seriously. I would expect it's a major delivery platform of sagemath functionality to users, so it should be taken seriously.

Anecdotally in my department, it seems at least as many people use the MacOS build as build from source. so +1 to this.

Given the Marc's macOS app and the fact that conda works great on macOS as well as Linux, these days the main reasons anyone builds Sage from source on macOS are (a) they want to contribute code to Sage (yay!) or (b) they've been using Sage for years and are unaware of the new binary installers.  As Marc mentioned, the SageMath 10.6 version of his app was downloaded 36,000 times; it's hard to imagine that more than a few hundred people built 10.6 from source on macOS, but I have not actual data.

Best,

Nathan

[Dima Pasechnik]

On 10 April 2025 07:45:09 GMT-05:00, Nathan Dunfield <nat...@dunfield.info> wrote:
>On Thursday, April 10, 2025 at 12:07:03 AM UTC-5 Dima wrote:
>
>> Probably not on the build system. But the app needs to work on *any*
>system.
>>
>>> Are you worried that sage would have trouble recognizing the python
>build as valid for its purposes?
>>
>No. Because sagelib (with meson build) is already a proper Python
>package, which should just shut up and get installed as a Python
>package of a Python. :-)
>(And the rest is just a semi-optional environment coming on top of
>sagelib, pretty much orthogonal to what's in the macOS app)
>
>
>To me, a "proper Python package" is something I can install with
>"random-python -m pip install blah" that pulls a binary wheel off PyPI that
>just works. If we're getting close to being able to do that, which would
>absolutely amazing, then why not wait until that's done so we can ditch
>sage-the-distribution completely?

Sorry, let's not try to shift the goalposts now.
Binary wheels (with self-contained binary extension modules) are a different story, and I am under the impression they are not of any use to the macOS app building.

As far as I can see, we are at the point where macOS app can switch to
using the meson build, with any Python you want. E.g. you can use the same Python as you use to package Jupyter (my understanding is that how macOS app does it).

With all non-python pre-reqs in place,
just run./bootstrap and pip to build sagelib, that's all.
No need to worry about a dodgy custom venv,
unhappy ./configure, etc.

We were told here that you want to build everything from source, and with this build you can do this just fine.
And your feedback on/fixes of will be very useful to improve it. We already get such feedback from Linux SageMath maintainers.

>
>While I understand the dislike for sage-the-distribution, removing Python
>(and perhaps some other collection of spkgs) creates
>sage-the-kinda-distribution which is less useful and, I suspect, even more
>fragile.

Less useful to whom? Yes, less useful as a hardcore, entertaining, and very time-consuming (for us, too) game, for a naïve user, who tries to build Sage on a brand-new macOS laptop with only XCode installed, or on a brand new, minimal, WSL install on a Windows box. Something that is most probably doomed to fail in a variety of entertaining ways.

The removal of stuff which doesn't go into binary wheels has to proceed incrementally,
and Python and its toolchain is a part to be removed.

And no, I don't see a reason for Sage getting more fragile with removal of python3 spkg.
To the contrary, it will be more robust. As I explained a number of times here already, our python3 and its toolchain are lagging behind. It's less fragile to use extensively tested on, and timely updated for, up to date OSes etc external packages, than try to repeat the upstream efforts, with delays and lack of testing.

Dima

>Best,
>
>Nathan
>
>

[Nathan Dunfield]

On Thursday, April 10, 2025 at 9:37:09 AM UTC-5 Dima wrote:

On 10 April 2025 07:45:09 GMT-05:00, I wrote:
>To me, a "proper Python package" is something I can install with
>"random-python -m pip install blah" that pulls a binary wheel off PyPI that
>just works. If we're getting close to being able to do that, which would
>absolutely amazing, then why not wait until that's done so we can ditch
>sage-the-distribution completely?

Sorry, let's not try to shift the goalposts now.

I didn't mean shift goalposts, I just misunderstand what you meant by the phrase "proper Python package"; the definition I'm familiar with goes farther at least on macOS/Windows.

 

Binary wheels (with self-contained binary extension modules) are a different story, and I am under the impression they are not of any use to the macOS app building.

Binary wheels are just fine for the macOS app, indeed it already uses a number of them.  For example, while "pillow" is a standard spkg, that version only supports a limited number of image types.  So that macOS app instead uses the one off PyPI to offer more functionality.

As far as I can see, we are at the point where macOS app can switch to
using the meson build, with any Python you want. E.g. you can use the same Python as you use to package Jupyter (my understanding is that how macOS app does it).

With all non-python pre-reqs in place,
just run./bootstrap and pip to build sagelib, that's all.
No need to worry about a dodgy custom venv,
unhappy ./configure, etc.

Interesting, where can I find a list of the non-python pre-reqs?  

 

We were told here that you want to build everything from source, and with this build you can do this just fine.

Building from source isn't necessary per se, for example a statically-linked self-contained wheel is fine.

However, nothing in the macOS app can be dynamically linked to a library in /opt/homebrew, for example.

Best,

Nathan

[Michael Orlitzky]

On 2025-04-10 12:10:07, Nathan Dunfield wrote:
>
> Interesting, where can I find a list of the non-python pre-reqs?

"meson setup" should tell you. Some of the dependency checks it does
are not as precise as the corresponding check from spkg-configure.m4
(it doesn't run "maxima" and parse the version number, for example)
but this due to lack of time rather than by design. OTOH many of the
dependency checks in spkg-configure are overly strict.

[Tobia...@gmx.de]

With all non-python pre-reqs in place,
just run./bootstrap and pip to build sagelib, that's all.
No need to worry about a dodgy custom venv,
unhappy ./configure, etc.

> Interesting, where can I find a list of the non-python pre-reqs?  

https://github.com/sagemath/sage/blob/871ba9daed15374d6b2ff1c533970f44b70f21e9/pyproject.toml#L101-L162

Btw, `bootstrap` is not required. git checkout + `pip install .` is all you need.

[Dima Pasechnik]

On Thursday, April 10, 2025 at 2:10:07 PM UTC-5 Nathan Dunfield wrote:

On Thursday, April 10, 2025 at 9:37:09 AM UTC-5 Dima wrote:

On 10 April 2025 07:45:09 GMT-05:00, I wrote:
>To me, a "proper Python package" is something I can install with
>"random-python -m pip install blah" that pulls a binary wheel off PyPI that
>just works. If we're getting close to being able to do that, which would
>absolutely amazing, then why not wait until that's done so we can ditch
>sage-the-distribution completely?

Sorry, let's not try to shift the goalposts now.

I didn't mean shift goalposts, I just misunderstand what you meant by the phrase "proper Python package"; the definition I'm familiar with goes farther at least on macOS/Windows.

"proper Python package" in the sense "it can be built as a  proper Python package", that's what I meant, sorry.

 

Binary wheels (with self-contained binary extension modules) are a different story, and I am under the impression they are not of any use to the macOS app building.

Binary wheels are just fine for the macOS app, indeed it already uses a number of them.  For example, while "pillow" is a standard spkg, that version only supports a limited number of image types.  So that macOS app instead uses the one off PyPI to offer more functionality.

Some time ago I proposed here to have just this, allow standard packages like pillow, pytest, etc. to be pip-installable from binary wheels,

and I was shouted down. Because, blah blah security blah blah no internet blah blah PyPI blah.

So, let's resurrect this argument? How about an official policy to allow this? Cause this way you are, a supposedly official distributor of

Sage on macOS, violating the official policy :-) But I digressed, sorry.

Anyway, I'll see how hard is to build a relocateable wheel with the meson build, using uv or pip.

Could be as easy as "uv build --wheel", perhaps.

 

As far as I can see, we are at the point where macOS app can switch to
using the meson build, with any Python you want. E.g. you can use the same Python as you use to package Jupyter (my understanding is that how macOS app does it).

With all non-python pre-reqs in place,
just run./bootstrap and pip to build sagelib, that's all.
No need to worry about a dodgy custom venv,
unhappy ./configure, etc.

Interesting, where can I find a list of the non-python pre-reqs?  

Well, I recall having an argument here for a proper slotting of spkgs into sub-directories, and I was told that I just can't handle the cognitive

load it takes to be a Sage dev. :-)

* They don't have leading underscores in names

* Among the standard spkgs (i.e. these that have "standard" in the file "type" in build/pkgs/<spkg name>),

 these are packages which are not having  version_requirements.txt file (because these are pip-installable)

Some of these packages could/should still be skipped (probably all matching py*), e.g. python3. It's all extremely logical and intuitive :-) Sorry for getting ironic.

Surely Linux Sage distibutors have such lists ready.

I'm planning to produce a complete range of Homebrew taps for these. There is even(stale)  https://github.com/sagemath/sage/issues/29395

to handle this - but note that Macaulay2 has a number of these we can just use already.

Dima

[Dima Pasechnik]

by the way, currently our settings give incorrect values for "meson
setup build" in the case
the build was done in venv; e.g. the venv python is python3.12, yet
meson find also installed on the
system, totally irrelevant, python3.13.

meson docs https://mesonbuild.com/Python-module.html say

If you are building Python extension modules against a Python
interpreter located in a venv or Conda environment, you probably want
to set python.install_env=auto; see Python module options for details.

But I don't understand where this "python.install_env=auto;" should be placed.

Dima

>
> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/Z_hI-isN8lWG4PKe%40mertle.

[Marc Culler]

On Thursday, April 10, 2025 at 9:53:04 PM UTC-5 Tobias wrote:

With all non-python pre-reqs in place,
just run./bootstrap and pip to build sagelib, that's all.
No need to worry about a dodgy custom venv,
unhappy ./configure, etc.

> Interesting, where can I find a list of the non-python pre-reqs?  

https://github.com/sagemath/sage/blob/871ba9daed15374d6b2ff1c533970f44b70f21e9/pyproject.toml#L101-L162

That pyproject.toml file contains these lines:

# Python 3.11 is the minimum supported version
target-version = "py311"

It would be extremely helpful to know how the mesonpy backend uses that target-version value.  Specifically, if I have compiled a python distribution and installed it somewhere on my system, and if I am using the pip from my installation to build a wheel, would pymeson build the wheel for my version of python, or might it (as Dima suggests) build for some other version that it finds somewhere else on the system which happens to meet  the minimum version requirement?

- Marc

[Dima Pasechnik]

I tried running "meson setup", which is probably meant for setting up new projects rather than getting info on the setup and dependencies.

I think the use of meson for building via pip or "uv pip" in a venv works correctly, as expected, it uses the python of the venv, and not something it finds somewhere...

Dima

>
>- Marc
>

[Marc Culler]

If we can get back to the original topic of this thread, I would like to report on the experiment I just finished.  That experiment was to update the python3 spkg to Python-3.13.3 (the latest python release) and then build Sage 10.7.b0 using the updated spkg and the usual build script that I always use for the Sage_macOS app.  (That script uses Sage's python3 spkg and Sages gfortran spkg and installs 42 optional packages without using anything from homebrew or conda.)

Updating the python3 spkg required changing a grand total of 4 lines of text:

* the version number was changed in package-version.txt

* 2 SHA hashes were updated in checksums.in

* 1 line was changed in spkg-build.in to stop testing whether the crypt module can be imported.  (The crypt module was removed from Python 3.13..)

With those 4 changes, Sage 10.7.b0 built without any issues whatsoever, python 3.13 included.

Starting from the resulting sage build I was then able to assemble a Sage 10.7 macOS app using our standard script for that job.  Once I finish getting Apple to notarize the app I will post it as a pre-release on our github site.

The obvious questions which this raises and which have still not been answered here are:  What is so wrong with this process?  Why do we have to break it?  Why can't we at least leave the Sage spkg in place until there is an actual, tested, working replacement for it?  (I am ignoring the other obvious question: what is so difficult about changing 4 lines of text in an spkg directory?)

I will attach the full patch file for updating the python3 spkg to version 3.13.3, in case someone wants to convert it to a PR.

- Marc

[Isuru Fernando]

Hey all,

Here's a possible solution to this problem: https://github.com/3-manifolds/Sage_macOS/pull/82

It needs these 4 PRs in sage applied to build sage: https://github.com/sagemath/sage/pulls/isuruf

I have checked that sage builds fine, but I haven't checked that the framework builds (and therefore not the size of a release).

Isuru

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/15523de1-226e-4b3e-bd6d-a91ece173cabn%40googlegroups.com.

[Dima Pasechnik]

On Fri, Apr 11, 2025 at 5:55 PM Marc Culler <marc....@gmail.com> wrote:
>
> If we can get back to the original topic of this thread, I would like to report on the experiment I just finished. That experiment was to update the python3 spkg to Python-3.13.3 (the latest python release) and then build Sage 10.7.b0 using the updated spkg and the usual build script that I always use for the Sage_macOS app. (That script uses Sage's python3 spkg and Sages gfortran spkg and installs 42 optional packages without using anything from homebrew or conda.)
>
> Updating the python3 spkg required changing a grand total of 4 lines of text:
> * the version number was changed in package-version.txt
> * 2 SHA hashes were updated in checksums.in
> * 1 line was changed in spkg-build.in to stop testing whether the crypt module can be imported. (The crypt module was removed from Python 3.13..)
>
> With those 4 changes, Sage 10.7.b0 built without any issues whatsoever, python 3.13 included.
>
> Starting from the resulting sage build I was then able to assemble a Sage 10.7 macOS app using our standard script for that job. Once I finish getting Apple to notarize the app I will post it as a pre-release on our github site.
>
> The obvious questions which this raises and which have still not been answered here are: What is so wrong with this process? Why do we have to break it?

Because it's a part of an overall wrong design (I hope I explained it
here at least twice). As a part of move to a better design, python3
spkg has to go.

Dima

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/15523de1-226e-4b3e-bd6d-a91ece173cabn%40googlegroups.com.

[Nils Bruin]

On Friday, 11 April 2025 at 15:55:39 UTC-7 marc....@gmail.com wrote:

The obvious questions which this raises and which have still not been answered here are:  What is so wrong with this process?  Why do we have to break it?  Why can't we at least leave the Sage spkg in place until there is an actual, tested, working replacement for it?  (I am ignoring the other obvious question: what is so difficult about changing 4 lines of text in an spkg directory?)

I get the impression that the concern is about maintenance load: when the project takes on the commitment to build python then it must update the python build package whenever this is required for supporting current operating systems. Apparently that clock ticks very quickly. So that requires frequent updates to the python package.

Alternatively, the project could set python as a prerequisite and just build on top of that. It shifts what outside clocks we need to keep up with: now we need to ensure that we support a wide enough range of pythons so that it is easy for people to install a python that works on all current operating systems.

I think the main function of having a build-from-source python package was to have a fall-back that allowed us to be very strict with our python requirements. It looks to me that the claim is that nowadays keeping a build-from-source python up to date is more work than keeping up-to-date with the python on which we run.

In a way, python is supposed to be an abstraction layer: it packages a lot of OS functionality behind a common python interface. So in principle there's a benefit to just deal with that abstraction and leave it to the python packagers to support different underlying platforms. Of course, python's abstraction isn't perfect (or perhaps we break through it on purpose for performance reasons), so we might not get all of that benefit.

What used to also be the case is that python itself would be quite in flux and that upgrading python from one version to another would need quite a bit of adjustment. I think that was why packaging python was generally deemed beneficial then.

Python has grown considerably and hopefully has turned a lot more stable (and/or distributions have gotten better of supporting older version of python for longer), so it could well be that the calculus has changed on this. That's definitely the position I see Dima and William take.

Certainly in the current situation of the python spkg we risk getting the worst of both worlds, if we want to do both well:

 - we need to ensure that the python spkg actually *can* build python on our supported platforms

 - we need to support a wide variety of pythons (including new ones) because people want the python spkg to be happy to have the python prerequisite satisfied by externally provided pythons.

So I can see where the aversion to staying in this transitionary phase comes from.

[Marc Culler]

On Sat, Apr 12, 2025 at 1:01 PM Nils Bruin <nbr...@sfu.ca> wrote:

I get the impression that the concern is about maintenance load: when the project takes on the commitment to build python then it must update the python build package whenever this is required for supporting current operating systems. Apparently that clock ticks very quickly. So that requires frequent updates to the python package.

Not if we follow your suggestion.  If your proposed special configure option is enabled, which causes Sage to build its own python3 from source, then there is one and only one version of python which gets built from source -- one which is known to be acceptable to Sage. If that special option is not set then Sage does whatever it does to find an acceptable python on the system and use it.  Those two courses of action are completely independent, except that when building from source the spkg must build a python3 which is acceptable to Sage.  No one should ever be in a position where they accidentally trigger the build from source because the special "use at your own risk" configure option is required to trigger such a build.

Alternatively, the project could set python as a prerequisite and just build on top of that. It shifts what outside clocks we need to keep up with: now we need to ensure that we support a wide enough range of pythons so that it is easy for people to install a python that works on all current operating systems.

When you say "now" you are talking about what Sage already does, not what it would have to do if something were changed. Sage *does* support a wide range of "system" pythons, which indeed adds a maintenance load and restricts which python language features can be used in Sage code.  The alternative (i.e. *always* building a specific python version from source) is not something that anyone has suggested.  In fact, it is not a crazy thing to do, but it would be a departure from what is currently being done.  I am not proposing that, and certainly no one else would propose such a thing.

I think the main function of having a build-from-source python package was to have a fall-back that allowed us to be very strict with our python requirements. It looks to me that the claim is that nowadays keeping a build-from-source python up to date is more work than keeping up-to-date with the python on which we run.

That claim is contradicted by the fact that upgrading from 3.12.5 to 3.13.3 required changing 4 lines of text in the spkg.  And 3 of the 4 were completely obvious.

What used to also be the case is that python itself would be quite in flux and that upgrading python from one version to another would need quite a bit of adjustment. I think that was why packaging python was generally deemed beneficial then.

But now that packaging work has been done (and is about to be trashed).  The amount of new work involved in upgrading the "build from source" part of the spkg is trivial, as I just demonstrated.  But please do not ignore what I said.  I did not say that the python3 "build from source" option must be maintained forever.  I said "Please keep it in place until there is a working, tested replacement ."  Let me repeat the "Please" part.  Please don't break our working build system before there is an actual working replacement.  And, yes, when I say "working" I mean that it works for building a self-contained relocatable Sage which can be used for the Sage_macOS app.  The status quo works by that definition.  Leaving the "build from source" option in place, exactly as it is now, or with the addition of the configure option that you proposed, would make it continue to work by that definition.  What does the Sage project gain by breaking our build when the alternative , i.e keeping the "build from source" option in place until there is a specific working alternative, has no cost?  (And, by the way, "people install python somehow" is not a specific working alternative.  It is not specific, it does not have a working implementation, and it is not really an alternative.)

Python has grown considerably and hopefully has turned a lot more stable (and/or distributions have gotten better of supporting older version of python for longer), so it could well be that the calculus has changed on this. That's definitely the position I see Dima and William take.

Certainly in the current situation of the python spkg we risk getting the worst of both worlds, if we want to do both well:

 - we need to ensure that the python spkg actually *can* build python on our supported platforms

Not if the "build from source" route is protected by a special "use at your own risk" configure option.  Add the "deprecated" tag to the "use at your own risk" tag if you like.

 - we need to support a wide variety of pythons (including new ones) because people want the python spkg to be happy to have the python prerequisite satisfied by externally provided pythons.

This is not an new risk.  This is what you are currently doing.  If you want to use "system" pythons from a wide range of linux distros then you need to support a wide variety of pythons, some of which will be new.  (Arch linux comes with 3.13 and even has a 3.14 "pre-release" package available.)  But no distro would ever use the Sage spkg to build python from source anyway.  So this really has nothing to do with the topic.  Nothing being discussed here would remove the existing requirement that Sage must support a wide variety of pythons, including new ones.

 

- Marc

 

[Dima Pasechnik]

Marc,
this is what many users need - to be able to install Sage into an existing Python environment; thus support is provided for a range of pythons.

Catering for the upside-down setup where Sage installs Python is a totally orthogonal user case, and you seem to be the only user who doesn't want to give it up.

> The
>alternative (i.e. *always* building a specific python version from source)
>is not something that anyone has suggested. In fact, it is not a crazy
>thing to do, but it would be a departure from what is currently being
>done. I am not proposing that, and certainly no one else would propose
>such a thing.

This is a non-flier for the reasons mentioned above, and previously on this thread.

>
>I think the main function of having a build-from-source python package was
>> to have a fall-back that allowed us to be very strict with our python
>> requirements. It looks to me that the claim is that nowadays keeping a
>> build-from-source python up to date is more work than keeping up-to-date
>> with the python on which we run.
>>
>
>That claim is contradicted by the fact that upgrading from 3.12.5 to 3.13.3
>required changing 4 lines of text in the spkg. And 3 of the 4 were
>completely obvious.

there is a slew of other related python packages which can just go, once python3 is gone, e.g. pip with its dependencies, etc. The particular upgrade you talk about is only easy because other dependencies (some of which could have been not a part of Sage in the first place) have been updated to python3.13-compatible state.

Once Sage is 300 or so spkgs lighter, it's much less work to maintain. Just leave the build and python toolchains, jupyter, etc. maintenance to experts, and concentrate on the core.

>
>What used to also be the case is that python itself would be quite in flux
>> and that upgrading python from one version to another would need quite a
>> bit of adjustment. I think that was why packaging python was generally
>> deemed beneficial then.
>>
>
>But now that packaging work has been done (and is about to be trashed).
>The amount of new work involved in upgrading the "build from source" part
>of the spkg is trivial, as I just demonstrated. But please do not ignore
>what I said. I did not say that the python3 "build from source" option
>must be maintained forever. I said "Please keep it in place until there is
>a working, tested replacement ." Let me repeat the "Please" part. Please
>don't break our working build system before there is an actual working
>replacement. And, yes, when I say "working" I mean that it works for
>building a self-contained relocatable Sage which can be used for the
>Sage_macOS app.

The working, tested in several ways replacement is there.
The new release isn't terribly close, so macOS app has time to iron out the kinks.
You even got a PR from Isuru to fix your problems
there.

Distros etc. typically have one previous to current version available too. E.g. Hombrew has 3.13 and 3.12, Gentoo Linux the same.

On the other hand, as already mentioned, there are external tools such as uv to get you a venv with a python the version of which the user can choose from a wide range. In this sense, even if the platform does not have a compatible with Sage python version natively, such a tool can be used.


Dima

[Marc Culler]

On Saturday, April 12, 2025 at 9:57:50 PM UTC-5 Dima wrote:

this is what many users need - to be able to install Sage into an existing Python environment; thus support is provided for a range of pythons.

That is what I said in my last message.  There is no need to repeat it back to me.

 

Catering for the upside-down setup where Sage installs Python is a totally orthogonal user case, and you seem to be the only user who doesn't want to give it up.

There were 34985 downloads of the two disk images for SageMath-10.5 which were created on 2024/12/04.  There have been 2288 downloads of the two disk images for SageMath-10.6 since they were created four days ago on 2025/04/08.  But you are unable to treat those people as being real Sage users.  I had hoped that your unpleasant attitude was not a reflection of how the Sage project as a whole views those users.  But maybe it is.

- Marc

 

[William Stein]

Marc, Your response seems to suggest that Dima is claiming that your
distribution of Sage is wrong or shouldn't exist. Nothing could be
further from the truth. We all very, very much want these Mac Sage
distributions to exist. The point is just that the creator of the
Mac Sage app is responsible for deciding on what Python to include,
rather than the Sage project itself.

-- William


--
William (http://wstein.org)

[Tobia...@gmx.de]

Marc, what is your opinion about replacing "building from source" in the Python spkg by "installing the prebuild pythons from astral/python-build-standalone"? Would this work for the MacOS app; and if not why?

Other popular projects, like anki and influxdb, seem to use these builds for their embedded Pythons (https://github.com/ankitects/anki/blob/8b2a64852b965b5e8fde97aa6f523ff64e061a96/build/ninja_gen/src/python.rs#L31, https://github.com/influxdata/influxdb/blob/5d7cb88f87ae1fdf3fb035a8c5002486f105a147/README_processing_engine.md?plain=1#L48-L54).

[Marc Culler]

On Sun, Apr 13, 2025 at 12:32 AM 'Tobia...@gmx.de' via sage-devel <sage-...@googlegroups.com> wrote:

Marc, what is your opinion about replacing "building from source" in the Python spkg by "installing the prebuild pythons from astral/python-build-standalone"?

Hi Tobias,

I don't know anything about astral.  But I am not at all concerned about being able to build python or find a pre-built python.  That is easy.   My concern is how to populate the Sage venv with such a python in a way which is guaranteed to work with the full Sage build process.  Since the Sage build process is about to change in some unspecified way about which I cannot predict any details, this conscern cannot be addressed until those changes are in place.  Once the changes are in place, our build process will have to be changed to match, as will  the process of making the Sage build self-contained and relocatable and the process of assembling the app.  I would like to make those changes to our process one time only, rather than have to redo them for each iteration of this transition of Sage's build process.

All I am asking is to leave the current python3 spkg "build from source" option in place, protected by requiring a special configure option to trigger its use, until these coming changes to Sage are in place and have become stabilized.

Please explain to me why that is such an unreasonable request.  We have heard repeatedly that everything we need to do is totally trivial, while this seemingly totally trivial request proposed by Nils is an unbelievably difficult thing which no one has any idea how to achieve.  It is pretty hard to buy that.

- Marc

[Marc Culler]

On Saturday, April 12, 2025 at 11:37:06 PM UTC-5 William wrote:

Marc, Your response seems to suggest that Dima is claiming that your
distribution of Sage is wrong or shouldn't exist. Nothing could be
further from the truth.

Really?  What does the following mean to you?

"I don't want to go into merits of the macOS app, but it's a highly non-standard by modern Python standards
thing which does not bring to users full functionality of Sage, and ties them up to a shifty expensive platform."

(Dima, Wednesday, April 9, 2025 at 6:44:31 PM UTC-5)

 - Marc

[kcrisman]

Marc, Your response seems to suggest that Dima is claiming that your
distribution of Sage is wrong or shouldn't exist. Nothing could be
further from the truth.

Really?  What does the following mean to you?

"I don't want to go into merits of the macOS app, but it's a highly non-standard by modern Python standards
thing which does not bring to users full functionality of Sage, and ties them up to a shifty expensive platform."

(Dima, Wednesday, April 9, 2025 at 6:44:31 PM UTC-5)

Yes it is hard to avoid the implication in *some* (not all) messages that true "end users" are not real users - and that most of the world runs on some "distro".  That this implication is not wholly the case is refuted by the thread on using meson having been motivated by the ability to build Sage (finally) natively on Windows - which I can only assume means that, if that project is fully successful, would mean the ability to eventually have Windows exe files for download, which would be stupendous.  

Still, it would be helpful for rhetoric around "only one user" be replaced by "all Mac users, many of whom do not have the time, expertise, or patience, or whatever, to build Sage from scratch using something like homebrew".  For better or for worse, Marc and his team have stepped into the gap to provide this incredibly valuable service.

[Sébastien Labbé]

I have been reading this thread silently like many other similar ping-pong exchanges on sage-devel in the past years. 

For one time, let me grab the ball, and share my opinion:

On Saturday, April 12, 2025 at 9:33:27 PM UTC+2 marc....@gmail.com wrote:

Please don't break our working build system before there is an actual working replacement. 

+1

 

- Marc

Sébastien 

PS: I you like watching ping-pong like me, here is another good thread between the two brothers from Montpellier France https://www.youtube.com/watch?v=hBvyU6guwm8

[Dima Pasechnik]

Nobody is going to "break" anything. You'll just need a proper Python to install Sage, like one of many pre-reqs already needed.

It's just fear-mongering. Building Sage will be less broken this way, not more broken.

Dima

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/20eb17b2-a989-481f-8104-f4f725a78fb4n%40googlegroups.com.

[Nils Bruin]

On Friday, 18 April 2025 at 10:07:12 UTC-7 dim...@gmail.com wrote:

Nobody is going to "break" anything. You'll just need a proper Python to install Sage, like one of many pre-reqs already needed.

It's just fear-mongering. Building Sage will be less broken this way, not more broken.

It looks to me that a consensus to move forward on this is in reach:

* Dima's preference is to (eventually) end up in a state where python is a prerequisite for sage and his main argument for that is: other projects have as purpose to provide python and they likely do a better job than we'd do.

* Marc and Sébastien have voiced some concerns about how smooth the transition to "python purely a prerequisite" would be. Given that we HAVE been offering the option to build python since the start, one would expect that some people's workflows are relying on that behaviour, so there are going to be wrinkles for those people. We in fact know that one example of that is the building process of the MacOS app.

It seems to me that the concerns of the two parties above aren't even conflicting: one is aiming for something they find technologically superior and ultimately more stable and reliable (and easier to maintain) whereas the other party is concerned that the transition will be too painful for them, or that they're forced to transition to something that may need fixing due to unforeseen shortcomings that come to light once they go through this forced transition. I haven't seen them object to the principle of the final goal.

So a middle ground would be to offer a security blanket during the transition: change the default behaviour of the python package for now to NOT build, but as a transition measure offer a configuration flag that restores the ability to build python from source. The clear goal of that must be that within the near future, no-one is actually activating that configuration flag, after which it can be removed with minimal impact. Once the python package has become just a stub to test if there is a python available that works properly, it will be easy to remove the package and instead make the test for python a normal prerequisite check.

The perceived conflict here doesn't look like it's technological at all. It seems much more an issue with trust. I realize it may be sobering to find that people basically say: "I don't trust your assessment", but just shouting "Just trust me" at an increased volume is very unlikely to persuade them. Instead, if there's a way forward that allows you to say "Fine, you don't have to trust me unconditionally; let's just do it in smaller steps and then you can check for yourself it's OK", you'll likely to do much better on gaining trust in the future. Plus, you'll arrive at the destination you were aiming for eventually anyway.

[William Stein]

On Fri, Apr 18, 2025 at 4:12 PM Nils Bruin <nbr...@sfu.ca> wrote:
>
> On Friday, 18 April 2025 at 10:07:12 UTC-7 dim...@gmail.com wrote:
>
> Nobody is going to "break" anything. You'll just need a proper Python to install Sage, like one of many pre-reqs already needed.
> It's just fear-mongering. Building Sage will be less broken this way, not more broken.
>
> It looks to me that a consensus to move forward on this is in reach:
>
> * Dima's preference is to (eventually) end up in a state where python is a prerequisite for sage and his main argument for that is: other projects have as purpose to provide python and they likely do a better job than we'd do.
>
> * Marc and Sébastien have voiced some concerns about how smooth the transition to "python purely a prerequisite" would be. Given that we HAVE been offering the option to build python since the start, one would expect that some people's workflows are relying on that behaviour, so there are going to be wrinkles for those people. We in fact know that one example of that is the building process of the MacOS app.
>
> It seems to me that the concerns of the two parties above aren't even conflicting: one is aiming for something they find technologically superior and ultimately more stable and reliable (and easier to maintain) whereas the other party is concerned that the transition will be too painful for them, or that they're forced to transition to something that may need fixing due to unforeseen shortcomings that come to light once they go through this forced transition. I haven't seen them object to the principle of the final goal.
>
> So a middle ground would be to offer a security blanket during the transition: change the default behaviour of the python package for now to NOT build, but as a transition measure offer a configuration flag that restores the ability to build python from source. The clear goal of that must be that within the near future, no-one is actually activating that configuration flag, after which it can be removed with minimal impact. Once the python package has become just a stub to test if there is a python available that works properly, it will be easy to remove the package and instead make the test for python a normal prerequisite check.
>

If the proposal to require an external Python is accepted, there could
still be our standard1-year deprecation period, during what you say
above is done.

> The perceived conflict here doesn't look like it's technological at all. It seems much more an issue with trust. I realize it may be sobering to find that people basically say: "I don't trust your assessment", but just shouting "Just trust me" at an increased volume is very unlikely to persuade them. Instead, if there's a way forward that allows you to say "Fine, you don't have to trust me unconditionally; let's just do it in smaller steps and then you can check for yourself it's OK", you'll likely to do much better on gaining trust in the future. Plus, you'll arrive at the destination you were aiming for eventually anyway.
>
>

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/a444cbd4-ff0b-4397-97ce-ad6da16f2679n%40googlegroups.com.



--
William (http://wstein.org)

[Dima Pasechnik]

On Fri, Apr 18, 2025 at 6:32 PM William Stein <wst...@gmail.com> wrote:

On Fri, Apr 18, 2025 at 4:12 PM Nils Bruin <nbr...@sfu.ca> wrote:
>
> On Friday, 18 April 2025 at 10:07:12 UTC-7 dim...@gmail.com wrote:
>
> Nobody is going to "break" anything. You'll just need a proper Python to install Sage, like one of many pre-reqs already needed.
> It's just fear-mongering. Building Sage will be less broken this way, not more broken.
>
> It looks to me that a consensus to move forward on this is in reach:
>
> * Dima's preference is to (eventually) end up in a state where python is a prerequisite for sage and his main argument for that is: other projects have as purpose to provide python and they likely do a better job than we'd do.
>
> * Marc and Sébastien have voiced some concerns about how smooth the transition to "python purely a prerequisite" would be. Given that we HAVE been offering the option to build python since the start, one would expect that some people's workflows are relying on that behaviour, so there are going to be wrinkles for those people. We in fact know that one example of that is the building process of the MacOS app.
>
> It seems to me that the concerns of the two parties above aren't even conflicting: one is aiming for something they find technologically superior and ultimately more stable and reliable (and easier to maintain) whereas the other party is concerned that the transition will be too painful for them, or that they're forced to transition to something that may need fixing due to unforeseen shortcomings that come to light once they go through this forced transition. I haven't seen them object to the principle of the final goal.
>
> So a middle ground would be to offer a security blanket during the transition: change the default behaviour of the python package for now to NOT build, but as a transition measure offer a configuration flag that restores the ability to build python from source. The clear goal of that must be that within the near future, no-one is actually activating that configuration flag, after which it can be removed with minimal impact. Once the python package has become just a stub to test if there is a python available that works properly, it will be easy to remove the package and instead make the test for python a normal prerequisite check.
>

If the proposal to require an external Python is accepted, there could
still be our standard1-year deprecation period, during what you say
above is done.

I'm fine with delaying this change until the 10.8 release cycle, but an even longer delay is too much, IMHO.

I propose to release 10.7 with the option proposed by Nils, and with python3 spkg removed in 10.8.

Dima

 

> The perceived conflict here doesn't look like it's technological at all. It seems much more an issue with trust. I realize it may be sobering to find that people basically say: "I don't trust your assessment", but just shouting "Just trust me" at an increased volume is very unlikely to persuade them. Instead, if there's a way forward that allows you to say "Fine, you don't have to trust me unconditionally; let's just do it in smaller steps and then you can check for yourself it's OK", you'll likely to do much better on gaining trust in the future. Plus, you'll arrive at the destination you were aiming for eventually anyway.
>
>
> --
> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/a444cbd4-ff0b-4397-97ce-ad6da16f2679n%40googlegroups.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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CACLE5GB1CtC16J__rqQXxDk%2B5DKwtuyH-VXj3fwKb8q%3D468vZA%40mail.gmail.com.

[Marc Culler]

I got the impression from comments in this thread that it would be possible to build python with the prefix directory of my choice and use that python as the "system python" for a build of Sage.  So I built a relocatable python 3.13 and installed it in a prefix directory.  Since the python installation is relocatable I can rename the prefix directory to whatever I want.

However, I am not able to find any way to convince Sage's configure script to use my python.  No matter what I try, it declares that there is no suitable system python.

Is this actually possible?  If so, what are the configure arguments needed to make sage use a python installed in /x/y/z?

(I.e. I want sage to build with python executable /x/y/z/bin/python3 and python library located in /x/y/z/lib/python3.13).

- Marc

[Tobia...@gmx.de]

On Saturday, April 19, 2025 at 7:12:16 AM UTC+8 Nils Bruin wrote:

So a middle ground would be to offer a security blanket during the transition: change the default behaviour of the python package for now to NOT build, but as a transition measure offer a configuration flag that restores the ability to build python from source. The clear goal of that must be that within the near future, no-one is actually activating that configuration flag, after which it can be removed with minimal impact. Once the python package has become just a stub to test if there is a python available that works properly, it will be easy to remove the package and instead make the test for python a normal prerequisite check.

 Alternatively, the python-spkg could be changed to install python via `uv python install 3.13` (instead of building from source). Then the public contract doesn't change and there is no impact for end-users (i.e. the configure + make workflow keeps unchanged even if one doesn't have a suitable python installed already), it's just the underlying implementation that changes. It's similar to how some of the python packages are now installed via their binary wheel instead of building them from source.

[Michael Orlitzky]

On 2025-04-20 14:26:12, Marc Culler wrote:
> However, I am not able to find any way to convince Sage's configure script
> to use my python. No matter what I try, it declares that there is no
> suitable system python.

What does config.log say is the reason for rejection?

My first guess is that

SAGE_SPKG_DEPCHECK([bzip2 liblzma libffi zlib], ...

is to blame. The "depcheck" macro tries to avoid library version
conflicts by ensuring spkg and system packages are not mixed and
matched. For example, if the bzip2 spkg is going to be used, we won't
use the system python because the system python is going to be linked
to a different copy of bzip2 (i.e. the system copy). If some other
sage package then links to both bzip2 and python, two copies of bzip2
could wind up loaded, and sage would crash.

IIRC you are building everything (except python, now) from SPKGs. If
so and if you are sure that your newly-built python was linked against
the sage copies of bzip2, zlib, etc., you can just ignore the DEPCHECK
(edit it out).

> Is this actually possible? If so, what are the configure arguments needed
> to make sage use a python installed in /x/y/z?
> (I.e. I want sage to build with python executable /x/y/z/bin/python3 and
> python library located in /x/y/z/lib/python3.13).

Yes, in general there are a bunch of things you may need to
override/append to use a library in a nonstandard location:

* -I for the headers at compile time
* -L for the linker to find your libraries at link time
* LD_LIBRARY_PATH / rpath to find the libraries at run time
* PATH to find executables at run time
* PKG_CONFIG_PATH because otherwise, even if you tweak the first
four, pkg-config will say the dependency doesn't exist

Then for sage, you also have to pass the spkg-configure.m4 check, and
there are no rules for that except to read it.

[Dima Pasechnik]

On Sun, Apr 20, 2025 at 4:26 PM Marc Culler <marc....@gmail.com> wrote:

I got the impression from comments in this thread that it would be possible to build python with the prefix directory of my choice and use that python as the "system python" for a build of Sage.  So I built a relocatable python 3.13 and installed it in a prefix directory.  Since the python installation is relocatable I can rename the prefix directory to whatever I want.

However, I am not able to find any way to convince Sage's configure script to use my python.  No matter what I try, it declares that there is no suitable system python.

What is the error you get ?

There are a number of checks done. First, there is a check that the version is between 3.11 and 3.13.

Then, that

bzip2, liblzma, libffi, zlib are available as "system" packages

(the idea of this check is to avoid several copies of these dylibs to lie around - it's assumed that they are

used to build your Python)

Then, there is a check that the modules sqlite3, ctypes, math, hashlib, socket, zlib, ssl, ensurepip can be imported.

And there is a test that sysconfig module isn't in a way misconfigured

 (but you can override it if you pass your Python as in the error message:

this is a misconfigured Python whose sysconfig compiler/linker flags contain -I or -L options, which may cause wrong versions of libraries to leak into the build of Python packages - see https://github.com/sagemath/sage/issues/31132; to use it anyway, use ./configure --with-python=$ac_path_PYTHON3]

)

HTH

Dima

 

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/02e9812e-84c8-4bca-b1ee-d05f6f421f6fn%40googlegroups.com.

[Marc Culler]

Thank you Michael,

My first guess is that
SAGE_SPKG_DEPCHECK([bzip2 liblzma libffi zlib], ...

I think that your guess is correct.

IIRC you are building everything (except python, now) from SPKGs. If
so and if you are sure that your newly-built python was linked against
the sage copies of bzip2, zlib, etc., you can just ignore the DEPCHECK
(edit it out).

Except that it is impossible for the newly-built python to be linked against the

sage copies of those libs, because the hewly-built python needs to be built

*before* sage is built, and therefore before those libs have been built.

I assume that what you really mean is that a newly-built python is not sufficient.

That python must be accompanied by all of those other libraries  and then sage

must also use the same libraries.  One way to do that might be to modify the sage

build process so that it builds the spkgs for those libraries and  then is forced to

halt while a separate python compilation is done in such a way that the python

modules which use those libraries can be linked against the versions which were

built by the corresponding sage spkgs. The sage build process could perhaps then

be restarted to build the rest of sage.

Of course that kind of craziness is exactly what I am hoping to avoid and what I do

not have to worry about with the current setup.  All of that complicated sequencing

is currently handled automatically because python3 is built by an spkg which specifies

those libraries as dependencies.

So the only practical way forward seems to be to install python in some context which

also includes all of those other libraries.  And somehow sage must be informed to

search in that context for all of those libraries.  (Running configure --help shows

options for saying whether to use the "system versions" of those libraries, but there

seems to be no way of providing a path to those options, and there is no hint about

how sage will actually decide whether the "system version" of one of those libraries

is usable.)

I expect that decision process isn't something general, such as checking for the

libraries in the same directory where the python3.13 directory is located, or in the lib

directory adjacent to the bin directory containing the python3 executable, or a hardwired

test which causes sage to use the versions of those libraries provided by Apple,.  I would

guess that instead there are some hardwired checks for whether homebrew or conda

is being used, and maybe a check of /usr/local.  If those  checks fail I would guess

that it just returns an error.  Does anyone know how sage decides whether there

is a usable "system version" of bzip2 or liblzma?

Of course the other complication is that I need to be able to make the sage installation

self-contained and relocatable.  I have done a lot of experimentation with that over the

last few days, which seems to indicate that it is not possible to make a standard "prefix"

installation of python relocatable - one has to use a "framework" installation to do that.

- Marc

[Dima Pasechnik]

Not really. You should be able to get away with appropriate settings of PATH,  CFLAGS and LDFLAGS (to point at

appropriate locations of the executables, headers, and dylibs.

 

If those  checks fail I would guess

that it just returns an error.  Does anyone know how sage decides whether there

is a usable "system version" of bzip2 or liblzma?

$ cat build/pkgs/bzip2/spkg-configure.m4
SAGE_SPKG_CONFIGURE([bzip2], [
    AC_CHECK_HEADER(bzlib.h, [
      AC_SEARCH_LIBS([BZ2_bzCompress], [bz2], [
        AC_PATH_PROG([bzip2_prog], [bzip2])
        AS_IF([test x$bzip2_prog = x], [sage_spkg_install_bzip2=yes])
      ], [sage_spkg_install_bzip2=yes])
    ], [sage_spkg_install_bzip2=yes])
])

That is, for bzip2, all you need is that your compiler knows where  bzlib.h is, that your linker knows where to find libbz2

(which should have BZ2_bzCompress function)

and that bzip2 executable is in your PATH

 $ cat build/pkgs/liblzma/spkg-configure.m4
SAGE_SPKG_CONFIGURE([liblzma], [
  SAGE_SPKG_DEPCHECK([xz], [
    dnl The library is actually installed by the xz spkg.
    AC_CHECK_LIB([lzma], [lzma_raw_decoder], [lzma_cv_liblzma=yes], [lzma_cv_liblzma=no])
    AC_CHECK_HEADER([lzma.h], [lzma_cv_lzma_h=yes], [lzma_cv_lzma_h=no])
    if test "$lzma_cv_liblzma" != "yes" -o "$lzma_cv_lzma_h" != "yes"; then
        sage_spkg_install_liblzma=yes
    fi
  ])
])

That is, for liblzma first it's checked that xz from the system is available; then, it's checked that your compiler

finds lzma.h, and your linker finds liblzma (with lzma_raw_decoder function).

speaking of xz, you need xz in your PATH. However,

please note the comments at the bottom of the following (that is, one doesn't really need xz)

 $ cat build/pkgs/xz/spkg-configure.m4
SAGE_SPKG_CONFIGURE([xz], [
        AC_CACHE_CHECK([for xz >= 4.999.0], [ac_cv_path_XZ], [
            AC_PATH_PROGS_FEATURE_CHECK([XZ], [xz], [
              xz_version=`$ac_path_XZ --version 2>&1 | cut -d' ' -f4 | $SED -n 1p`
              AS_IF([test -n "$xz_version"], [
                  AX_COMPARE_VERSION([$xz_version], [ge], [4.999.0], [
                      ac_cv_path_XZ="$ac_path_XZ"
                      ac_path_XZ_found=:
                  ])
              ])
            ])
            AS_IF([test -z "$ac_cv_path_XZ"], [sage_spkg_install_xz=yes])
        ])
], [dnl REQUIRED-CHECK
        dnl Issue #30948: All dependencies on "xz" are merely build-time dependencies
        dnl on the xz binary (for unpacking the tarball in sage_bootstrap.uncompress.tar_file
        dnl - when sage-bootstrap-python is so old that it cannot do that by itself).
        dnl Packages that depend on actual xz or liblzma should depend on the liblzma spkg.
        AS_IF(["$SAGE_BOOTSTRAP_PYTHON" -c "import lzma" 2>& AS_MESSAGE_LOG_FD], [
             sage_require_xz=no
        ])
])

HTH

Dima

Of course the other complication is that I need to be able to make the sage installation

self-contained and relocatable.  I have done a lot of experimentation with that over the

last few days, which seems to indicate that it is not possible to make a standard "prefix"

installation of python relocatable - one has to use a "framework" installation to do that.

- Marc

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/a88d22ca-b9a4-485a-9912-d140338d8f7cn%40googlegroups.com.

[Marc Culler]

Here is one thing that I find strange.  The only external libraries that are needed to compile python on macOS are openssl and (if you want the real gnu thing) readline.  I know, because I have compiled python on macOS.  The dependencies like libbz2, liblzma, libffi, libz and even libsqlite3 are all provided with the OS.  They are available on any macOS system and accessible by any xcode compiler.  Yet Sage does not find "usable system versions" of many of them.  (It does find bzip2, for some weird reason, and maybe the liblzma behavior is explained by the fact that Apple does not provide an xz executable even though it does provide liblzma.)

The following are available as part of the OS, for example:

libbz2, libblas, libdbm, libffi, libf77lapack, liblapack, libiconv, liblzma, libncurses, libsqlite3, libz (many versions)

The point, to be clear, is that Sage will currently not accept the versions of these libraries provided by Apple, but python will accept the subset which it needs.  Yet somehow the claim is being made that the "remove the python spkg" project will make it be the case that sage will accept a python built locally even though, if done in the obvious way, such a python build will use many of those Apple libraries.  At the same time there is a worry about the crashes that will occur if python uses one version of a library and some sage package uses a different one.  Yet there is no option to use the Apple libraries to satisfy the requirements of Sage packages which use versions of those libraries.

These are all reasons why the current python spkg exists.  And this is part of why I think it is inevitable that the end of the "remove the python spkg" story will be that the only supported external pythons on macOS will be homebrew and conda.  I am not allergic to homebrew, but I don't think anyone other than me is going to pay any attention to the issues of how to make the sage distribution self-contained, relocatable and compatible with a wide range of macOS versions when it is built against a homebrew distribution.  Despite all of the glib pronouncements about how trivial this must be, I don't think it will be a trivial thing to do.  On the other hand it is obvious, from the fact that an idiot like me was able to do it, that creating a self-contained relocatable Sage distribution with the current python spkg configuration *is* trivial.

- Marc

[Michael Orlitzky]

On 2025-04-21 19:41:35, Marc Culler wrote:
>
> Except that it is impossible for the newly-built python to be linked
> against the
> sage copies of those libs, because the hewly-built python needs to be built
> *before* sage is built, and therefore before those libs have been built.

The sage build process actually involves two versions of python. One
is used as part of the build process, and another is built (and later
used) to run sage.

The first one is quietly mentioned as part of the _prereq package and
has very few constraints. It's the one that is built for later use
with sage that needs to have all of its libraries be compatible with
everything else.

> That python must be accompanied by all of those other libraries and
> then sage must also use the same libraries. One way to do that
> might be to modify the sage build process so that it builds the
> spkgs for those libraries and then is forced to halt while a
> separate python compilation is done in such a way that the python
> modules which use those libraries can be linked against the versions
> which were built by the corresponding sage spkgs. The sage build
> process could perhaps then be restarted to build the rest of sage.

Yes, you would have to build those libraries first before building the
python that will eventually be used with sage. But the python used to
invoke the build system up to that point can be arbitrary.

It will be a headache.

The ./configure option to re-enable python is a good compromise.
*Eventually* you should have your own build scripts for the system
stuff, but in the meantime, the two goals that I can personally take
ownership of are,

1. I don't think end users should ever be trying to build python; if
they get that far, some other error has likely compounded. It
would be much better to suggest that they find a suitable system
python (and bzip2, and liblzma, etc.) instead.

2. Largely as a result of the first item, I don't want to maintain
the python SPKG, e.g. be forced to upgrade the python SPKG and
mess with ./bootstrap and ./configure whenever we make changes
to sagelib.

In our current example, removing python on its own does not perfectly
address the first item, because it's still possible that users could
build the liblzma SPKG, and in that case, the system python would be
linked to some other version of liblzma. The sage build system thinks
this is an error (and in some cases it probably is). To rectify it, we
should also insist that zlib, bzip2, libffi, and liblzma come from the
system -- in other words, we should disable those SPKGs too. I have a
feeling that this would be a lot more politically viable if we left
behind a ./configure override for those packages as well.

[Dima Pasechnik]

On Tue, Apr 22, 2025 at 8:53 AM Marc Culler <marc....@gmail.com> wrote:

Here is one thing that I find strange.  The only external libraries that are needed to compile python on macOS are openssl and (if you want the real gnu thing) readline.  I know, because I have compiled python on macOS.  The dependencies like libbz2, liblzma, libffi, libz and even libsqlite3 are all provided with the OS.  They are available on any macOS system and accessible by any xcode compiler.  Yet Sage does not find "usable system versions" of many of them.  (It does find bzip2, for some weird reason, and maybe the liblzma behavior is explained by the fact that Apple does not provide an xz executable even though it does provide liblzma.)

The following are available as part of the OS, for example:

libbz2, libblas, libdbm, libffi, libf77lapack, liblapack, libiconv, liblzma, libncurses, libsqlite3, libz (many versions)

The point, to be clear, is that Sage will currently not accept the versions of these libraries provided by Apple, but python will accept the subset which it needs.  Yet somehow the claim is being made that the "remove the python spkg" project will make it be the case that sage will accept a python built locally even though, if done in the obvious way, such a python build will use many of those Apple libraries.  At the same time there is a worry about the crashes that will occur if python uses one version of a library and some sage package uses a different one.  Yet there is no option to use the Apple libraries to satisfy the requirements of Sage packages which use versions of those libraries.

That's the first time I see a complaint that the Apple's libraries used for Python or its modules are not accepted.

This is something we can fix, to an extent. And surely we can adjust the check for xz.

Regarding macOS native bzip2, it just happens to pass our tests, nothing weird about it.

Regarding libz, it, implictly, needs pkg-config. One can hand-craft pkg-config .pc file for it, then macOS native libz probably will work, I didn't try.

Regarding Apple's lapack/blas, i.e. Accelerate Framework libraries, there are upstream packages which use openblas on macOS - the most prominent such package is scipy.

scipy maintainers dropped Accelerate Framework as it was lagging many lapack/blas versions behind compared to the lapack/blas reference implementation (and openblas).

(there were more bugs IIRC).

I am not sure we want different Python modules using different lapack/blas implementations.

Dima

 

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/edf5c543-d148-4e29-9f1e-c2219f9e8e1bn%40googlegroups.com.