Sage 10.8.beta1 released

[Volker Braun]

As always, you can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html

Docbuild is still not in a great shape, on the plus side I couldn't reproduce the recent race conditions any more. On the downside this test now always fails:

sage-runtests --long --warn-long 30.0 --random-seed=0 src/sage/misc/sagedoc.py  # 1 doctest failed

but imho its better to get another beta out instead of trying to fix this while the build system is changed. But please somebody fix that.

4cdd703f8b3 (github/develop, tag: 10.8.beta1) Updated SageMath version to 10.8.beta1
cbf32b0a7b5 gh-40675: Remove failing 'ubuntu-focal' from default CI platforms
f3ee42320cc gh-40673: bump meataxe to 1.0.2
02677a357cf gh-40668: remove some deprecations in plot folder
c13346cf7ba gh-40664: remove deprecations in quadratic forms
8f2305901bb gh-40660: remove a deprecated class in structure
fa188af2924 gh-40659: remove 2 deprecated functions in symbolic/
c26f6082aea gh-40658: remove a deprecated method in typeset/
6435352d424 gh-40656: remove deprecated method in matroid.pyx
19100862f65 gh-40655: remove some deprecated methods in matrix/
c3c52716be8 gh-40654: Fix release workflow to trigger changelog workflow
48499dc0a82 gh-40651: StandardTableaux_residue passes incorrect args on its super().__init__() call
a5f24007d2a gh-40647: remove deprecated method in manifolds/subset
8f81a5a409d gh-40646: remove deprecated method in coxeter3 interface
f8a63a45c67 gh-40645: remove deprecated algorithm choice in generic_graph
06a41ced9b1 gh-40644: bump plantri to version 5.5
e779d17fa0c gh-40642: bump nauty to version 2.9.0
02b250f6612 gh-40641: remove one deprecated method in difference_family
89935994ec9 gh-40640: Ensure that random polynomial generation is nonzero to avoid test fail
5c6393e463c gh-40639: trying to avoid CommutativeRing in schemes
cf36caca1a3 gh-40637: fixing E117
090cd35ffda gh-40633: Update versions for matplotlib and dependencies
cab9896dba3 gh-40631: some care for pep E231 in modular folder
91e9a622e4a gh-40629: fixes in f_matrix

cd41fa08cb1 gh-40627: Improved string representation of Cartesian product when all factors equal
f72bb10d82d gh-40620: Fix a typo in workflow
b305b81eef1 gh-40615: Added support for vector.random
b2392aae2a6 gh-40613: Fix Ctrl-C segfaults in sage.libs.gap
decf49dc941 gh-40610: enumerate cycles in undirected graphs by _all_cycles_iterator_vertex
ee8ece8ba72 gh-40607: src/sage/libs/gap: add some missing "const"
96d32d9f718 gh-40606: Fix artifact with this name already exists error
17491c75d4b gh-40599: Fix documentation for Drinfeld modules
51e8a9acd77 gh-40597: Migrate pdf-doc build to meson
2272ab78455 gh-40595: Remove spurious diffs in doc previews
91b1b764d9c gh-40594: Fix segmentation fault in libgap function call
b08d1e2b17c gh-40589: Use LaTeX commands instead of Unicode characters
56026456cbc gh-40579: Row rank profile / row pivots: direct extraction from echelon form over prime fields
3939fbf8bcc gh-40577: Meson: use pkg-config for more libraries
b37c26247ea gh-40574: Re-enable abs_integrate for Maxima integration
0bb40ed496f gh-40556: Avoid mutating value field of constructed Integer
e85de39b1c8 gh-40542: Implement composition of pseudomorphisms
a6b81bc5676 gh-40522: Ore modules over PID
c79dcfc5c3d gh-40473: Handling the automorphism group of the trivial sublattice
2dea3c83db6 gh-40471: Remove the experimental "surf" package
fcc7a8ca37b gh-40460: move zlib to prereqs, remove zlib spkg
e808bd9c226 gh-40440: Hom spaces between Drinfeld modules
366ea00d682 gh-40437: cleanup and annotations in congroup_gammaH.py
22c48fa8485 gh-40436: Remove useless limitations in Drinfeld modules
2a6752f1a03 gh-40434: gcd and lcm of isogenies of Drinfeld modules
e55feb28e66 gh-40433: Constructor for the Carlitz module
99ae29d51fe gh-40432: Implement relative Frobenius for Drinfeld modules
561070b9c41 gh-40430: Use the variable name τ instead of t for Drinfeld modules
c1a62af52da gh-40332: Use `python3 -m sage.doctest` in doctest results report if not using `sage-runtests`
dda9605ddb7 gh-40166: Format toml files and add linter check
1591b6d9fc4 gh-40142: Meson: test archlinux on CI and migrate devcontainer
e48fde667e3 gh-40081: Integration of a new optional package for Khovanov homology
efeb8f47cec gh-39554: creating axioms for lattices
cb030433d73 (tag: 10.8.beta0) Updated SageMath version to 10.8.beta0

[John H Palmieri]

On OS X with various homebrew packages: it seems that the html documentation is not built by default anymore. When did this change?

[Eric Gourgoulhon]

Hi, 

I've just built Sage 10.8.beta1 from a fresh git clone, after having removed by hand the dead  https://ftp.rediris.es/mirror/sagemath/ from upstream/mirror_list, following this advice: https://groups.google.com/g/sage-release/c/CqAD2Y1f_5E/m/lHBJEgEPAAAJ

The build finished successively and Sage works in console mode, but the command

sage -n jupyterlab

fails to find any SageMath kernel... 

This issue seems to have reported already for Sage 10.8.beta0:

 https://groups.google.com/g/sage-release/c/CqAD2Y1f_5E/m/oUgrS1S3AAAJ

Eric.

[Eric Gourgoulhon]

Le mercredi 27 août 2025 à 23:41:34 UTC+2, John H Palmieri a écrit :

On OS X with various homebrew packages: it seems that the html documentation is not built by default anymore. When did this change?

Already for Sage 10.7, the html doc was not built by default; so this must have been changed in some Sage 10.7.beta*

Eric. 

 

[Dima Pasechnik]

On August 28, 2025 11:15:17 AM CDT, Eric Gourgoulhon <egourg...@gmail.com> wrote:
>Hi,
>
>I've just built Sage 10.8.beta1 from a fresh git clone, after having
>removed by hand the dead https://ftp.rediris.es/mirror/sagemath/

><https://ftp.rediris.es/mirror/sagemath/spkg/upstream/cython/cython-3.1.3.tar.gz> from

>upstream/mirror_list, following this advice:
>https://groups.google.com/g/sage-release/c/CqAD2Y1f_5E/m/lHBJEgEPAAAJ
>The build finished successively and Sage works in console mode, but the
>command
>
>sage -n jupyterlab
>
>fails to find any SageMath kernel...
>This issue seems to have reported already for Sage 10.8.beta0:
> https://groups.google.com/g/sage-release/c/CqAD2Y1f_5E/m/oUgrS1S3AAAJ

a fix for this is attempted in #40700

>
>Eric.
>

[John H Palmieri]

This seems like something that should have been announced, perhaps even discussed before making the change, since it's a significant change to the build and installation procedure. 

[Eric Gourgoulhon]

Le jeudi 28 août 2025 à 20:49:23 UTC+2, John H Palmieri a écrit :

This seems like something that should have been announced, perhaps even discussed before making the change, since it's a significant change to the build and installation procedure. 

Indeed, this should have been announced here:

https://github.com/sagemath/sage/wiki/Sage-10.7-Release-Tour

Eric.

[Enrique Artal]

There was another (worse) way to solve it, to downgrade setuptools; actually this downgrading also solved another issue, namely the complete building of sagelib for any run of make.

[Dima Pasechnik]

Sticking to the old half-btoken tools while the world moves on is not a solution.

We have a bunch of 10-year old code (SageKernelSpec class etc) meant to do what nowadays can be done with one call to "jupyter kernelspec".

[Enrique Artal]

Sorry, I do not understand the answer. Something in the upgrade of setuptools provoke that after any small change (or even none), sagelib is completely rebuilt.

[Kwankyu Lee]

On Saturday, August 30, 2025 at 1:00:48 AM UTC+9 Dima Pasechnik wrote:

Sticking to the old half-btoken tools while the world moves on is not a solution.

We have a bunch of 10-year old code (SageKernelSpec class etc) meant to do what nowadays can be done with one call to "jupyter kernelspec".

Are you sure that  SageKernelSpec class was created due to lack of "jupyter kernelspec" 10 years ago? 

It is not sound that some code is regarded half-broken because it is 10 years old. It worked well just before something (setuptools or build system) has changed recently in our codebase.

The missing sagemath kernel issue is a way more serious problem than sticking to the old tools. If we don't have a good solution, sticking to the old tools is a reasonable solution.   

[Marc Culler]

On Sunday, August 31, 2025 at 8:09:51 PM UTC-5 Kwankyu Lee wrote:

On Saturday, August 30, 2025 at 1:00:48 AM UTC+9 Dima Pasechnik wrote:

Sticking to the old half-btoken tools while the world moves on is not a solution.

We have a bunch of 10-year old code (SageKernelSpec class etc) meant to do what nowadays can be done with one call to "jupyter kernelspec".

Are you sure that  SageKernelSpec class was created due to lack of "jupyter kernelspec" 10 years ago? 

I am pretty sure that it was not created just for that reason, and that it does things which the jupyter command does not du (such as make sure that threejs is availabe.). However, even If all it does is to avoid forcing users to run a separate mysterious command before being able to use a jupyter notebook, then it is doing an important job.  Notebooks should work "out of the box".

- Marc

[Kwankyu Lee]

I am pretty sure that it was not created just for that reason, and that it does things which the jupyter command does not du (such as make sure that threejs is availabe.). 

Moreover it solved the problem of copying the massive sage documentation when the kernel is installed, by symlinking instead. 

 

 

[Dima Pasechnik]

On September 1, 2025 8:04:47 PM CDT, Kwankyu Lee <ekwa...@gmail.com> wrote:
>
>
>I am pretty sure that it was not created just for that reason, and that it
>does things which the jupyter command does not du (such as make sure that
>threejs is availabe.).

in 2015 jupyter was pretty new, and Sage code,
written by Volker, converted what was there for ipython to jupyter. Maybe he remembers why it went this way.
Perhaps "jupyter kernelspec install" was just not available then.

>
>
>Moreover it solved the problem of copying the massive sage documentation
>when the kernel is installed, by symlinking instead.

symlinking is flaky across VMs and filesystems. E.g. if you run Jupyter in a Windows browser (or in VSCode), with Sage running in WSL, then it seems to me one cannot avoid "jupyter kernelspec install".
Well, yes, it's about 2.3Gb of data, but with the current capacity and cost of SSDs it's not something to worry about.



>
>
>
>

[Marc Culler]

On Monday, September 1, 2025 at 11:18:36 PM UTC-5 Dima Pasechnik wrote:

symlinking is flaky across VMs and filesystems. E.g. if you run Jupyter in a Windows browser (or in VSCode), with Sage running in WSL, then it seems to me one cannot avoid "jupyter kernelspec install".
Well, yes, it's about 2.3Gb of data, but with the current capacity and cost of SSDs it's not something to worry about.

I think most of this statement is highly questionable.

Symlinking either works or does not work within a given context.  If there were an example showing that it fails in this situation then that would be something to worry about.  If not, then talk about "flakiness" is just talk.

Also, 2.3GB is almost twice the size of the entire sage AppImage and is larger than the maximum size allowed for a release download in GitHub.  The sage AppImage weighs in at 1.25GB, and occupies 1.25 GB on the user's disk, even though it contains the complete English documentation for sage.

 The way this works in the AppImage is that the html files stored in the AppImage are gzipped.  The English documentation shrinks to only 120MB when redundant files are removed and the rest are gzipped.  All browsers are able to decompress gzipped html files on the fly with no noticeable performance lag.  So the AppImage provides its own webserver which delivers gzipped files when the reference() command or the jupyter notebook "Help" menu are used to view documentation.

Claiming that 2.3GB (or 10GB in the case of a full build of Sage) is not something to worry about is pretty crazy, even if there do exist some contexts where it is not an issue.  There are other contexts where it is a serious issue.

- Marc

[Dima Pasechnik]

On Tue, Sep 2, 2025 at 8:37 AM Marc Culler <marc....@gmail.com> wrote:
>
>
>
> On Monday, September 1, 2025 at 11:18:36 PM UTC-5 Dima Pasechnik wrote:
>
> symlinking is flaky across VMs and filesystems. E.g. if you run Jupyter in a Windows browser (or in VSCode), with Sage running in WSL, then it seems to me one cannot avoid "jupyter kernelspec install".
> Well, yes, it's about 2.3Gb of data, but with the current capacity and cost of SSDs it's not something to worry about.
>
>
> I think most of this statement is highly questionable.
>
> Symlinking either works or does not work within a given context. If there were an example showing that it fails in this situation then that would be something to worry about.

Symlinks don't work on Windows filesystems. Your Appimage works in
this sense on Windows+WSL, but it's not via symlinks, but via a
built-in webserver.
Do all jupyter clients support these remote compressed docs?

> If not, then talk about "flakiness" is just talk.
>
> Also, 2.3GB is almost twice the size of the entire sage AppImage and is larger than the maximum size allowed for a release download in GitHub. The sage AppImage weighs in at 1.25GB, and occupies 1.25 GB on the user's disk, even though it contains the complete English documentation for sage.
>
> The way this works in the AppImage is that the html files stored in the AppImage are gzipped. The English documentation shrinks to only 120MB when redundant files are removed and the rest are gzipped. All browsers are able to decompress gzipped html files on the fly with no noticeable performance lag.
> So the AppImage provides its own webserver which delivers gzipped files when the reference() command or the jupyter notebook "Help" menu are used to view documentation.

OK, so the 2.3Gb issue goes away if we compress and prune the docs,
and only only then do

jupyter kernelspecs install

Is this what you are saying (because 120Mb is really not something to
worry about) ?

>
> Claiming that 2.3GB (or 10GB in the case of a full build of Sage) is not something to worry about is pretty crazy, even if there do exist some contexts where it is not an issue. There are other contexts where it is a serious issue.

I don't even see a noticeable delay while running "jupyter kernelspecs
install", assuming kernel and the target are on the same filesystem.
Perhaps spyware^H^H^H^H antivirus can slow this to a halt, almost, I
won't be surprised.
So there is no "if". It's just a way to do the job, without extra
built-in http servers, on the fly decompression, all these constantly
CPU-clogging things.

I don't know where 10Gb come from - pdf docs? Docs for all the
optional and standard packages?

Dima



>
> - Marc
>
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-release/6d8a678e-7b28-4d25-9c31-7a55f6596dd1n%40googlegroups.com.

[Marc Culler]

On Tuesday, September 2, 2025 at 9:19:40 AM UTC-5 Dima Pasechnik wrote:

OK, so the 2.3Gb issue goes away if we compress and prune the docs,
and only only then do

jupyter kernelspecs install

Is this what you are saying (because 120Mb is really not something to
worry about) ?

 

Yes.

By the way, Sage has custom code in the SageKernel class which makes the docs available from the Help menu in a jupyter notebook.  It does not handle the gzipped files, so we modify it.  For that we use the cocoserver pypi package.

I don't know where 10Gb come from - pdf docs? Docs for all the
optional and standard packages?

% du -sch sage
 11G sage
 11G total

That is the image we use as a starting point for both Sage_macOS and sage_appimage.  It includes many optional packages as well as the html documentation in all languages and the huge amount of detritus left over after a build (which we remove).  It does not include pdf docs.

 So 10GB (well, really 11GB) is just the disk footprint of a normal Sage installation when Sage is built from source.

- Marc

[Marc Culler]

It is also worth paying some attention to reality when it comes to the cost of disk storage.  The cheapest macBook Air model costs $900 and comes with a 256GB ssd.  Upgrading to 512GB costs $200 extra.  Users who are not willing to invalidate their warranty and are not mechanical geniuses cannot replace the ssd with a larger one by themselves.  So, for many students, the marginal cost of disk space is $800/TB. Most students will choose the 256GB drive rather than pay $200 more.  Of course you can buy a decent 1TB portable ssd for less than $100, but no one wants to lug one of those around so they can plug it in when they need to run Sage.

- Marc

PS It does not help to tell them that they chose the wrong OS.

PPS Many students are using older computers with even smaller disks.

[Dima Pasechnik]

given that Mathematica install is at least 5Gb, and an install of NVIDIA tools is about 18Gb,
2Gb does not look like a lot.

Anyway, a straightforward "jupyter kernelspec install --user" copies much more stuff than needed (all the .so extension modules are about 60%, with the rest being uncompressed html docs - 0.7Gb, and few other things).

There should be a way to avoid copying, .so, it's really looking like a  bad Python path management.

[kcrisman]

It is also worth paying some attention to reality when it comes to the cost of disk storage.  The cheapest macBook Air model costs $900 and comes with a 256GB ssd.  Upgrading to 512GB costs $200 extra.  Users who are not willing to invalidate their warranty and are not mechanical geniuses cannot replace the ssd with a larger one by themselves.  So, for many students, the marginal cost of disk space is $800/TB. Most students will choose the 256GB drive rather than pay $200 more.  Of course you can buy a decent 1TB portable ssd for less than $100, but no one wants to lug one of those around so they can plug it in when they need to run Sage.

- Marc

PS It does not help to tell them that they chose the wrong OS.

PPS Many students are using older computers with even smaller disks.

Thank you very much for this post. 

[Enrique Artal]

Besides of these discussion, I would like to point out what happens with the last version of setuptools. With 73.0.1, the kernel of jupyter is correctly installed. For me, by linking this kernel to a place where system jupyter can find it, I can use it with no problem with system jupyterlab. Another issue of the new version of setuptools is that sagelib is rebuilt completely each time.

[Kwankyu Lee]

On Wednesday, September 3, 2025 at 8:55:01 PM UTC+9 enriqu...@gmail.com wrote:

Besides of these discussion, I would like to point out what happens with the last version of setuptools. With 73.0.1, the kernel of jupyter is correctly installed. For me, by linking this kernel to a place where system jupyter can find it, I can use it with no problem with system jupyterlab. Another issue of the new version of setuptools is that sagelib is rebuilt completely each time.

Right. The current discussion around Dima's solution is off the right path.

Since we know that downgrading setuptools to the previous version solves these serious regressions, we should just

(1) downgrade the setuptools for now. This is easy.

(2) investigate why the new setuptools introduces regressions, with time. This is difficult, but is not urgent.

I guess that (2) is less difficult and safer than trying to replace the "old" time-tested tools with something new. 

Regarding sage development, we should be conservative than revolutionary, for stability.

[Dima Pasechnik]

On Wed, Sep 3, 2025 at 6:34 PM Kwankyu Lee <ekwa...@gmail.com> wrote:
>
> On Wednesday, September 3, 2025 at 8:55:01 PM UTC+9 enriqu...@gmail.com wrote:
>
> Besides of these discussion, I would like to point out what happens with the last version of setuptools. With 73.0.1, the kernel of jupyter is correctly installed. For me, by linking this kernel to a place where system jupyter can find it, I can use it with no problem with system jupyterlab. Another issue of the new version of setuptools is that sagelib is rebuilt completely each time.
>
>
> Right. The current discussion around Dima's solution is off the right path.

I've opened
https://github.com/jupyter/jupyter_client/issues/1070
to ask why they copy too much data, and why they don't do the right
thing with `--sys-prefix` rather than `--user`.

>
> Since we know that downgrading setuptools to the previous version solves these serious regressions, we should just
>
> (1) downgrade the setuptools for now. This is easy.

No, why? there is no urgency to do this last resort option for the
beta versions - unless someone has a habit of doing real exploratory
maths work using a Sage beta,
something which isn't a good idea.
Besides, `jupyter kernelspec install` works, it just consumes 2Gb more
disk space than needed, so it's not a huge deal in 2025.

> (2) investigate why the new setuptools introduces regressions, with time. This is difficult, but is not urgent.

upgrading setuptools has a clear priority, as it is needed by a host
of other package upgrades, supporting Python 3.14, etc.

>
> I guess that (2) is less difficult and safer than trying to replace the "old" time-tested tools with something new.

if you don't have anyone who knows the old code and is willing to
debug it, it's very natural to look for a shortcut, using
tools which were nonexistent, or in development, while the

>
> Regarding sage development, we should be conservative than revolutionary, for stability.

For stability, we need to be at the same toolchain as the rest of the
scientific Python universe, and not falling behind.
If you want to have sagemath in the Linux distros such as arch and
gentoo, you need to use their toolchain, in particular setptools
version 80 or newer.

Dima

[Enrique Artal]

I understand your point and unfortunately I have no solution so far. But I tried to use #40700, with small issues using sage -n jupyterlab and with failures using system jupyter.

On the other side, I open #40742, and while the branch in github uses the updated version of setuptools, in my machine I downgraded it because after changing any file because of mistakes and rebuilding the compiling time was OK, rebuilding sagelib always would be a nightmare. 

Writing this I wonder if it is a good idea to use intermediate versions of setuptools to track the changes that cause the mulfunction.

Enrique..

[Dima Pasechnik]

On Thu, Sep 4, 2025 at 4:34 PM Enrique Artal <enriqu...@gmail.com> wrote:
>
> I understand your point and unfortunately I have no solution so far. But I tried to use #40700, with small issues using sage -n jupyterlab and with failures using system jupyter.
> On the other side, I open #40742, and while the branch in github uses the updated version of setuptools, in my machine I downgraded it because after changing any file because of mistakes and rebuilding the compiling time was OK, rebuilding sagelib always would be a nightmare.
> Writing this I wonder if it is a good idea to use intermediate versions of setuptools to track the changes that cause the mulfunction.

I don't think there is any malfunction on the setuptools side - it's
some obsolete code in Sage that fails to work with modern setuptools.

Anyway, I hope https://github.com/sagemath/sage/pull/39030 is merged soon,
and then you will get working jupyter.

Dima

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/sage-release/c8ce24b4-0d35-4807-a0fe-11bda4d11782n%40googlegroups.com.

[Enrique Artal]

If it helps till 78.1.1 jupyter kernel is built and sagelib is not completely rebuil; in 79.0.1 both problems appear. Maybe looking at the changelog someone can figure out what can be changed in sagemath.

It is just an opinion from a person having programmer skills quite far from all of you, but it may be interesting to be able to build sage with meson and classical tools, at least for a while.

Enrique.

[Enrique Artal]

Sorry, I meant 79.0.0

[Kwankyu Lee]

> Sorry, I meant 79.0.0

Thanks. This helps. Between 78.1.1 and 79.0.0, there is only this change: (from setuptools changelog)

- Removed support for 'legacy-editable' installs. (#917)
 

   Newer versions of ``pip`` no longer run the fallback command  ``python setup.py develop`` when the ``pyproject.toml`` file is present.
   This means that setting the environment variable  ``SETUPTOOLS_ENABLE_FEATURES="legacy-editable"``  will have no effect when installing a package with ``pip``.

In anticipation of this, Matthias prepared https://github.com/sagemath/sage/issues/34209 long time ago. However,

> Anyway, I hope https://github.com/sagemath/sage/pull/39030 is merged soon, and then you will get working jupyter.

#39030 will soon introduce a  revolutionary upheaval to the sagelib build system. Then perhaps Matthias' solution would be obsolete. 

So we should wait for the next beta and fix things later.