SageMath 10.10

[Martin R]

Dear all,

since a nice number is coming up in a couple of months from now, I would like to encourage you to mention your favourite pull request which should be go into that release here.  I think it would be nice to make a collaborative effort to get them in!

Best wishes,

Martin

[Martin R]

Let me start, in the hope of sparkling discussion.

My favourite goal would be to finally get rid of old-style parents (semi-deprecated since 2008), in particular `parent_old.pyx`, `parent_base.pyx`, `parent_gens.pyx`, `Parent._set_element_constructor`.

The main obstacle is, if I understand correctly, that `Ring` inherits from `ParentWithGens`.

Frederic has worked a lot on this issue, and his latest PR is https://github.com/sagemath/sage/pull/40213

I don't know what the roadmap after this ticket would look like.

Martin

[Martin R]

minor update: https://github.com/sagemath/sage/pull/40213 is already in.

I guess, we can call sage a finished product now :-)

[Tobia...@gmx.de]

Nice initiative! I would would like to continue working on using more standard tooling with sage:

1. Make sage pip-installabe on macos + recent ubuntu. That is, after installing all required system packages on those systems, a simple "pip install sagemath" (or "pip install ." from a git checkout) should yield a working sage. No make, no configure, just pip install.

2. Make it possible to run all doctests with pytest (so that we can deprecate sage's own test runner)

3. Add more typing

4. Migrate doc builds to just be a simple "sphinx build" instead of the custom doc builder that we currently have

[David Coudert]

For the graph module, substantial improvements have been made for the construction of immutable graphs.

Almost all (di)graph constructors have now a parameter to decide if the returned graph should be mutable or immutable (*).

I hope this will be finalized for 10.10.

Furthermore,  some substantial improvements have been obtained for the construction of (Di)Graph (https://github.com/sagemath/sage/pull/41988) for some inputs. This is clearly faster now.

We will try to finalize this work for other input formats.

The overall goal is speed up the construction and manipulation of immutable graphs, in particular by avoiding unnecessary conversions from/to mutable/immutable graphs.

This might not be fully completed for 10.10.

Best,

D.

(*) let me thanks again the reviewers of the PRs.

[kcrisman]

1. Make sage pip-installabe on macos + recent ubuntu. That is, after installing all required system packages on those systems, a simple "pip install sagemath" (or "pip install ." from a git checkout) should yield a working sage. No make, no configure, just pip install.

Just curious: how might William's sagelite (https://groups.google.com/g/sage-devel/c/XPFqMFq3Apw) release fit into that/provide a model?

That said, if one gets a recent Python from homebrew, I suspect that "pip" won't work directly, usually I get some messages about venv and managed environments.  Since I have neither time nor skills to help on this, I hesitate to suggest a "brew install sagemath", but if that fits in the vision you and others have on build systems, it would certainly be an interesting option - not replacing the current excellent work on the MacOS download, obviously, but useful for certain users.

 

2. Make it possible to run all doctests with pytest (so that we can deprecate sage's own test runner)

That is also a really intriguing option. 

[Dima Pasechnik]

On Thu, May 7, 2026 at 9:30 AM kcrisman <kcri...@gmail.com> wrote:
>
>
> 1. Make sage pip-installabe on macos + recent ubuntu. That is, after installing all required system packages on those systems, a simple "pip install sagemath" (or "pip install ." from a git checkout) should yield a working sage. No make, no configure, just pip install.
>
>
> Just curious: how might William's sagelite (https://groups.google.com/g/sage-devel/c/XPFqMFq3Apw) release fit into that/provide a model?
>
> That said, if one gets a recent Python from homebrew, I suspect that "pip" won't work directly, usually I get some messages about venv and managed environments.

yes, you need to create a venv, or use uv - it's not rocket science...

> Since I have neither time nor skills to help on this, I hesitate to suggest a "brew install sagemath", but if that fits in the vision you and others have on build systems, it would certainly be an interesting option - not replacing the current excellent work on the MacOS download, obviously, but useful for certain users.

We're very close to have a "normal" Homebrew-based install of Sage,
just like we have on Linux distros such as Arch and Gentoo.

That is to say, with Homebrew packages installed from a number of
sources (this will have to be made into a coherent list), such as the
Homebrew proper (i.e. "brew install foobar") and Homebrew taps
macaulay2/tap (from Macaulay2 project) -
https://github.com/Macaulay2/homebrew-tap -
and dimpase/tap (that's from me and Tobias Diez - to be moved to
something like sagemath/tap)
https://github.com/dimpase/homebrew-tap
we should be able to build Sage (sagelib, to be precise) as a normal
Python package, using pip.

And the latter, hopefully, should be possible to wrap into a Homebrew
formula, too.

Dima

>
>
> 2. Make it possible to run all doctests with pytest (so that we can deprecate sage's own test runner)
>
>
> That is also a really intriguing option.
>

> --
> 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/4f0c8665-8dc4-4ba8-a4be-b13a13bb770dn%40googlegroups.com.

[Tobia...@gmx.de]

On Thursday, May 7, 2026 at 4:30:05 PM UTC+2 kcrisman wrote:

1. Make sage pip-installabe on macos + recent ubuntu. That is, after installing all required system packages on those systems, a simple "pip install sagemath" (or "pip install ." from a git checkout) should yield a working sage. No make, no configure, just pip install.

Just curious: how might William's sagelite (https://groups.google.com/g/sage-devel/c/XPFqMFq3Apw) release fit into that/provide a model?

Wiliam's fork makes heavy use of the recent work of making sagemath pip-installable. As a bit of background, when you run `pip install sagemath`, two things might happen:

1. Pip is building sagemath from source using external dependencies that are installed system-wide (eg via homebrew).

2. Pip is downloading a pre-built version of sagemath (a so-called wheel), that bundles a compiled sagemath and its external dependencies.

What I would like to work on for 10.10 is the first option. Wiliam's project is providing pre-built wheels (point 2) for a subset of sage's functionality. Once we have a fully functional "install from source using pip" version of sage, it will be relatively easy to build wheels - so Wiliam's fork would then no longer be needed as we could build wheels for all of sagemath ourselves.

And yes, having a standard homebrew formula for sagemath would be great as well.

 

[kcrisman]

> That said, if one gets a recent Python from homebrew, I suspect that "pip" won't work directly, usually I get some messages about venv and managed environments.

yes, you need to create a venv, or use uv - it's not rocket science... 

Evidently, and I've done it when pressed.  But it's still a pain in the behind.

We're very close to have a "normal" Homebrew-based install of Sage,
just like we have on Linux distros such as Arch and Gentoo. 

I saw this on the -release post as well, that's very good news!  Thanks also to Tobias for clarification on your current goal versus William's sagelite status, that is helpful.

[Michael Orlitzky]

After the decade-long diversion preventing the sage library from
having a real build system, we can finally pass options to meson
to enable or disable features, such as -Dmeataxe=disabled.

We also have our feature system that attempts to detect all of these
things at runtime, repeatedly:

$ sage -t example.py
Running doctests with ID 2026-05-10-08-13-30-6cdf578c.
Running with SAGE_LOCAL='/usr'
Using --optional=sage
Features to be detected: 32_bit,4ti2,benzene,bliss,buckygen,
conway_polynomials,coxeter3,csdp,cvxopt,cvxopt,
database_cremona_ellcurve,database_cremona_mini_ellcurve,
database_cubic_hecke,database_ellcurves,database_graphs,
...

This is ugly (I'm slowly working on that), but more to the point, is
often a waste of time. If I disable meataxe when I build sage, it's a
waste of resources to repeatedly check for it, because it's just not
going to be there. And if by some miracle Sage does determine that
meataxe is available... I still don't want to run the tests for it,
because I disabled it, and presumably had a good reason to do so.

After a lot of thought and discussion, we came up with a plan for
this:

* https://github.com/sagemath/sage/discussions/41067

Option 3 is now implemented at,

* https://github.com/sagemath/sage/pull/41550

It's a relatively safe change at this point. We introduce a new
BuildFeature class, and a meson option called defer_feature_checks.
The existing features (such as meataxe) are made a BuildFeature, and
the value of -Dmeataxe=enabled is recorded at build time. The feature
test then just returns the recorded value, i.e. does not poke around
on the system. For backwards compatibility, defer_feature_checks=True
retains the old behavior, and is the default in the Sage distribution.

The PR is mostly boilerplate conversion of the feature classes for the
existing options in the meson.options file. After the conversion,
build-time features no longer appear in the

Features to be detected: 32_bit,4ti2,...

list, so it will slowly get less ugly if you opt in. And for people
packaging sage, it becomes a lot easier to know what its dependencies
are, and to avoid surprise test failures when a user installs an
optional package whose tests have bit-rotted.