Sage development norms and procedures

[John H Palmieri]

Here are some recent occurrences in Sage development:

1. The documentation is not built by default.

2. There has been the assertion that Conda is the recommended approach for compiling from source.

3. Kwankyu has brought up some issues about github release creation.

4. Historically (at least in my experience) Sage developers were careful to maintain backwards compatibility, whereas there are at least some now who are willing to break things and then maybe fix them later. Item 3 arose, and some other issues arose, because code was removed without carefully thinking about the consequences.

5. Others may be able to add other items here, but perhaps we don't need to.

I am not writing this to debate any of these individual issues, but to raise a point: the norm in Sage development has been, when there is a significant change in how Sage will work/built/doctest/whatever, there has been a discussion on sage-devel, with all of the pluses and minuses, often followed by a vote. I view at least items 1 and 2 as major changes, but I don't remember seeing such discussions or votes on sage-devel. 

Do we want to continue with this norm?

This is of course tied up with the governance discussion in which some people have been participating, and coming up with a governance structure might solve this problem, but since I don't think a governance structure is imminent, it makes sense to raise this question now.

Item 4 is a change in approach/philosophy within the Sage project, I believe. Opinions about this?

-- 

John

[Michael Orlitzky]

On 2025-09-25 15:47:24, John H Palmieri wrote:
> Here are some recent occurrences in Sage development:
>
> 1. The documentation is not built by default.

Is there an issue about this? I don't build the docs so I honestly
don't know. What I do know is that when we recently switched to meson
for building the sage library, the docs were built unconditionally. I
know because I had to (re)add the option to disable them:

https://github.com/sagemath/sage/commit/aca4aed1192

They are however enabled by default, so AFAIK they should be built,
and the intention was never to change that.

> 2. There has been the assertion that Conda is the recommended approach for
> compiling from source.

This has been beaten to death, e.g.

* https://groups.google.com/g/sage-devel/c/AvH3xq2bCfo/m/Rrr0Chp0DAAJ
* https://github.com/sagemath/sage/discussions/39272

Ultimately, what we should recommend is what is most likely to
work. The bottom line is that sage distribution is rotting. Speaking
for myself, now that I'm not forced to maintain hundreds of duplicate
packages, I don't. And from the git log on build/pkgs, I'm not
alone. With no one maintaining the packages there, it ceases to be
what is most likely to work. Conda is a good alternative, but I also
get the impression that the suggestion du jour is not the point of
your post.

This issue is unique in that no one needs to do anything for the sage
distribution to bit-rot. Packages become out-of-date and incompatible
with newer libraries/compilers all on their own; no malice on behalf
of any sage developers is involved. No one has decided to switch to
Conda, it's just slowly becoming the better choice. Some may find that
regrettable, but it's not something that can be addressed by
fiat. Reversing the trend would involve a huge, ongoing time
commitment, indefinitely. People are free to work on it if they want
to, but we can't legislate it.

[Tobia...@gmx.de]

On Friday, September 26, 2025 at 6:47:25 AM UTC+8 John H Palmieri wrote:

3. Kwankyu has brought up some issues about github release creation.

4. ... Item 3 arose, and some other issues arose, because code was removed without carefully thinking about the consequences.

As can be seen in https://github.com/sagemath/sage/actions/workflows/dist.yml?page=3, the release creation is failing since May. The these failures were a result of external changes in the GH API/actions involved at the release step, not any deletions on our (my) side. So this is another example of the natural bit rot that Michael mentions.

I think one reason you’re bringing this up is that the current release cycle has been especially tough on sage-the-distro users:

1. First came the setuptools update, which broke the Jupyter kernel and caused some annoying recompilation issues.

2. Then the move to the Meson build backend introduced a few doctest and docbuild hiccups on some systems.

3. And now, the cleanup work after that switch has brought along a couple more bugs (like the current sage-conf problem).

Since I was closely involved in points 2 and 3, I really want to say I’m sorry for the headaches this has caused. My goal was never to make things harder for anyone. PR #39030 was a big, nine-month effort, non-trivial but necessary, and honestly, given the state of sage-the-distro, I’m relieved it went as smoothly as it did.

That said, you’re absolutely right: I should have done a better job communicating these changes ahead of time, if only to set expectations and help everyone brace for the bumps along the way.

[Dima Pasechnik]

To elaborate, most spkgs are Python packages (and most of them are dependencies of just a few: notebook, sphinx, pip, python3).
None of them are patched, so it's purely a duplication, manual, error prone, and time consuming, of what one can install from PyPI or a similar source in few commands.

Now, updating a few packages often breaks some other packages, for it's humanely impossible for one person to do dependency resolution for 300 interconnected packages by hand.
And bitrotting they are - just today I found a few spkgs which are not Python 3.14 compatible,
while working on <https://github.com/sagemath/sage/issues/40890>

My modest proposals to fix a part of it, by allowing standard packages to be pip-installable were voted down.

Now, may I ask, why do these people, who have voted my proposals down, do not keep up with constantly updating the spkgs, doing the necessary reviewing of such updates, etc?

Many of them are (almost) never seen contributing code or reviews. They at most come here and complain that Sage is hard to install, that they object to such and such changes, etc. Have they assumed that the extra work they demanded by their votes will be magically done for them?


I think the only way out is to get rid of these spkgs.
We don't need a bundled python, or a bundle notebook/jupyterlab. Sage can very well be made into a pipx package (and sagelib into a pip package).

Many non-python packages are dead wood, in the sense one can always have an alternative from your OS or distro.
E.g. gcc/gfortran, readline, etc.
I have been working on removing such packages; you might have noticed that zlib, bzip2, pkg-config spkgs are gone (moved to pre-requisites) in 10.7; there is a positively reviewed PR to remove boost spkg (i.e. move it to pre-requisites).


Dima

>