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

>

[Kwankyu Lee]

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

Here are some recent occurrences in Sage development:

1. The documentation is not built by default.

Previously "make" built doc. Now it doesn't. This change affects all developers using sage-the-distro. 

As such, It should have been announced in sage-devel. I don't know if it was. 

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

This is a major change. This should be approved in sage-devel before it is officially adopted (appear in docs).

 

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

We are keeping changelogs here: https://www.sagemath.org/changelogs/index.html. They are automatically generated by a few github workflows.

To keep the format (contributions divided by releases) of the changelogs, I made the PR https://github.com/sagemath/sage/pull/39194.

Recently https://github.com/sagemath/sage/pull/40709 removed the code from #39194 without any discussion.

The author and the reviewer of #40709 made no efforts to fix the regression, as seen in https://github.com/sagemath/sage/pull/40840 and https://github.com/sagemath/sage/pull/40843. 

 

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.

I agree. Item 3 is one but trivial example. There could be other non-trivial items related with the work of conda/meson-based sage. 

The sage community did not approve transition from the sage-the-distro-based sage to conda/meson-based sage, as we did for python3 transition and github migration.

Hence conda/meson-based sage should be developed while not breaking sage-the-distro-based sage. 

However, the main developer of conda/meson-based sage proposes PRs without testing with sage-the-distro-based sage. An example: https://github.com/sagemath/sage/pull/40841. 

Even though he is not "willing to break things and then maybe fix them later", such a PR, if merged without a careful review, is likely to break sage-the-distro-based sage.

[Georgi Guninski]

> 4. Historically (at least in my experience) Sage developers were careful to maintain backwards compatibility,

I think a major backwards compatibility is the order of keyword
arguments with default values.
Several year ago I had to do mass replacements in my code.

I needed Graph.edges(labels=False) and I did `G.edges(False)`.
Sage release made the first argument of .edges `vertices` instead of
`labels` and my code failed.

[Dima Pasechnik]

On Sun, Sep 28, 2025 at 10:52 AM Kwankyu Lee <ekwa...@gmail.com> wrote:
>
> On Friday, September 26, 2025 at 7:47:25 AM UTC+9 John H Palmieri wrote:
>
> Here are some recent occurrences in Sage development:
>
> 1. The documentation is not built by default.
>
>
> Previously "make" built doc. Now it doesn't. This change affects all developers using sage-the-distro.

And it is a positive change, as one does building of the code more
often than building of the code and the docs.

> As such, It should have been announced in sage-devel. I don't know if it was.

And this is fine. You were not visibly doing anything Sage-related for
at least half a year, after a minor scandal,
with you demanding more "respect" legacy of a developer removed from
the project for major misconduct.

>
> 2. There has been the assertion that Conda is the recommended approach for compiling from source.
>
>
> This is a major change. This should be approved in sage-devel before it is officially adopted (appear in docs).

No, why? It's just how things are at the moment. Conda is the easiest
cross-platform way to install Sage, full stop.
It's hard to argue otherwise. If someone writes that 2+2==4 in the
manual, will you demand an approval for this too?

>
>
> 3. Kwankyu has brought up some issues about github release creation.
>
>
> We are keeping changelogs here: https://www.sagemath.org/changelogs/index.html. They are automatically generated by a few github workflows.
>
> To keep the format (contributions divided by releases) of the changelogs, I made the PR https://github.com/sagemath/sage/pull/39194.
>
> Recently https://github.com/sagemath/sage/pull/40709 removed the code from #39194 without any discussion.
>
> The author and the reviewer of #40709 made no efforts to fix the regression, as seen in https://github.com/sagemath/sage/pull/40840 and https://github.com/sagemath/sage/pull/40843.

#40709 was fixing a much much bigger regression than this.
https://github.com/sagemath/sage/pull/39194 solves a very minor (I
think non-existent, and I am going to put it to a vote here) issue in
a hard to maintain way.

CI tasks like one tackled in #40709 like this are hard to fix,
as you never know whether it will actually work when deployed in the
real, in this case while making a
new release.

Yes, there was a lot of CI code added, removed or redone lately. I
don't know why you have made such a fuss about your 20 lines.

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

Please stop making unfunded assumptions about someone being careless or not.
It's impossible to think about consequences of removing of something
that's broken and serves an unclear purpose, while its author
is not around. Note that it is about the CI code, which is as a rule
hardly ever documented.

>
>
> I agree. Item 3 is one but trivial example. There could be other non-trivial items related with the work of conda/meson-based sage.
>
> The sage community did not approve transition from the sage-the-distro-based sage to conda/meson-based sage, as we did for python3 transition and github migration.

Oh, do you mean to say that abandoning python2 needed some sort of approval?

> Hence conda/meson-based sage should be developed while not breaking sage-the-distro-based sage.

Nothing got broken in sage the distro in any serious way. Few quirks
might be due to the move to
the meson-based build of sagemath (the library). We have bid a
well-deserved farewell to the old setuptools-and-what-no-based
spaghetti,
which in part resulted in creation of passagemath.
By the way, the latter is being aggressively "marketed" as the "right"
Sage, including sticking incompatible with SageMath
bits into Sage downstream projects, see e.g.
https://github.com/abelfunctions/abelfunctions/commit/0d8a4d5a9a69943ed3ecde4c929e23473cc187d8

Clearly, sage the distro is overdue for a major overhaul, as we are
drowning in necessary for going forward updates
such as https://github.com/sagemath/sage/pull/40892 which means doing
manually what tools like pip and uv do automatically.

>
> However, the main developer of conda/meson-based sage proposes PRs without testing with sage-the-distro-based sage. An example: https://github.com/sagemath/sage/pull/40841.
>
> Even though he is not "willing to break things and then maybe fix them later", such a PR, if merged without a careful review, is likely to break sage-the-distro-based sage.

Anyone can propose a PR which is not tested in some ways.
By the way, I have given that PR a negative review a while ago, what
is your problem with it?

Dima

[Dima Pasechnik]

The whole thread is about backwards compatibility for the build system
and related development information - ways the relevant content is
delivered (sic!).
Build systems evolve, development platforms evolve, websites evolve.
We obviously don't offer compatibility with Mercurial VCS and trac
patchquilts
we used to use.
Nobody talks about Sage code here (except perhaps setup.py - which
went out of Python fashion years ago)

>
> --
> 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/CAGUWgD9iUXKDERnpL9z%2BsYrp%2B1tWNV7%2B%3D5BcVOHwAkqbaptuCw%40mail.gmail.com.

[John H Palmieri]

On Monday, September 29, 2025 at 8:01:58 AM UTC-7 dim...@gmail.com wrote:

On Sun, Sep 28, 2025 at 10:52 AM Kwankyu Lee <ekwa...@gmail.com> wrote:
>
> On Friday, September 26, 2025 at 7:47:25 AM UTC+9 John H Palmieri wrote:
>
> Here are some recent occurrences in Sage development:
>
> 1. The documentation is not built by default.
>
>
> Previously "make" built doc. Now it doesn't. This change affects all developers using sage-the-distro.

And it is a positive change, as one does building of the code more
often than building of the code and the docs.

I understand that opinion, but it should have been discussed by the Sage community before being implemented.

 

> As such, It should have been announced in sage-devel. I don't know if it was.

And this is fine. You were not visibly doing anything Sage-related for
at least half a year, after a minor scandal,
with you demanding more "respect" legacy of a developer removed from
the project for major misconduct.

I don't know if I should read this as an attack on Kwankyu or a more general message, conveying something like, if you don't post here much, if you are not very involved in Sage development, then you should not express your opinion here. Either way: good job! This is a great way to make the Sage community more open and welcoming! Thanks!

 

>
> 2. There has been the assertion that Conda is the recommended approach for compiling from source.
>
>
> This is a major change. This should be approved in sage-devel before it is officially adopted (appear in docs).

No, why? It's just how things are at the moment. Conda is the easiest
cross-platform way to install Sage, full stop.
It's hard to argue otherwise. If someone writes that 2+2==4 in the
manual, will you demand an approval for this too?

There is a difference between saying "conda seems to work best these days" and "conda is the recommended approach". The second version connotes that a person or people in authority have deemed this to be the case, and I don't think that has happened. (The only authority would come from a discussion and vote on sage-devel, given our current governance structure.) In contrast, the first version is clearly just an opinion of an individual poster.

 

>
>
> 3. Kwankyu has brought up some issues about github release creation.
>
>
> We are keeping changelogs here: https://www.sagemath.org/changelogs/index.html. They are automatically generated by a few github workflows.
>
> To keep the format (contributions divided by releases) of the changelogs, I made the PR https://github.com/sagemath/sage/pull/39194.
>
> Recently https://github.com/sagemath/sage/pull/40709 removed the code from #39194 without any discussion.
>
> The author and the reviewer of #40709 made no efforts to fix the regression, as seen in https://github.com/sagemath/sage/pull/40840 and https://github.com/sagemath/sage/pull/40843.

#40709 was fixing a much much bigger regression than this.
https://github.com/sagemath/sage/pull/39194 solves a very minor (I
think non-existent, and I am going to put it to a vote here) issue in
a hard to maintain way.

CI tasks like one tackled in #40709 like this are hard to fix,
as you never know whether it will actually work when deployed in the
real, in this case while making a
new release.

Yes, there was a lot of CI code added, removed or redone lately. I
don't know why you have made such a fuss about your 20 lines.

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

Please stop making unfunded assumptions about someone being careless or not.
It's impossible to think about consequences of removing of something
that's broken and serves an unclear purpose, while its author
is not around. Note that it is about the CI code, which is as a rule
hardly ever documented.

If someone removes a line saying something like "from X import Y", then the author and reviewer should just do a quick search to see if Y is still used anywhere, rather than just leaving it as an undefined symbol. I think it's fair to call that careless.

If someone is working on the build system and neither the author nor the reviewer think to try it out on a fresh git clone, I think it's also fair to call that careless.

Others may disagree with me.

[John H Palmieri]

Obviously people are welcome to talk about Sage code here. Please do continue to post: do not take Dima's response as any discouragement to post about Sage code.

[William Stein]

On Mon, Sep 29, 2025 at 9:12 AM John H Palmieri <jhpalm...@gmail.com> wrote:
> On Monday, September 29, 2025 at 8:01:58 AM UTC-7 dim...@gmail.com wrote:
> > Previously "make" built doc. Now it doesn't. This change affects all developers using sage-the-distro.
>
> And it is a positive change, as one does building of the code more
> often than building of the code and the docs.
>
> I understand that opinion, but it should have been discussed by the Sage community before being implemented.

I would personally welcome a broader discussion (and perhaps even a
vote) on whether the docs should be built by default. From my own
experience, building the documentation takes quite a long time, and
I’ve often found myself needing to look up the flag to disable it. For
that reason, I’m relieved that it’s now off by default. At the same
time, I realize I don’t fully understand what the trade-offs
are—specifically, what we lose by not building the docs automatically,
and how significant the time cost is for different use cases.


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

[Nils Bruin]

It seems to me there are two things that arise in conflict here:

 - some people who see, unannounced, big changes and failures happen.

 - developers who see certain changes as necessary to keep their maintenance burden manageable and other changes as desirable because there are benefits to be had.

The first group are not automatically opposed to the changes that the second group want. It's just that their first encounter with the changes is a negative one and therefore they react negatively.

If there had been a discussion about the proposed changes, it is very well possible that the consensus would have been that it's worth to make the change (that is mainly: embrace meson and/or, change when docs are built due to cost) and at the very least, after a course of action was converged on, people would have at least had some warning that instability in building was imminent due to some large changes being merged.

Autocratic rule by just forcing decisions through does not invite buy-in and ultimately will narrow the community; not grow it. It would probably help if we get a more well-defined governance structure in place for sagemath (mainly because it will help to still be able to act in situations where consensus cannot easily be reached) but we won't be able to avoid the discussion to see to what degree we can reach consensus. That step is necessary to maintain a welcoming community. I don't think sagemath is viable by running it as a collaboration of a small group of maintainers and release engineers. So we're stuck with the politics of making decisions in a large group of people.

[Dima Pasechnik]

As meson is capable of incremental compilation and correct dependency tracking, a change in a pyx file in sagelib wouldn't even need

"./sage -b" run---something that wasn't always working well, and so one needed "make build" instead, which 

meant a  coffee-break :-)

The necessary rebuild is triggered by a mere restart of ./sage, as far as I understand.

On the other hand, docbuilding doesn't have a dependency tracking builtin, and it never had.

I am not sure about the timeline, but the plan is to get rid of Sage's custom docbuilding, and use as much sphinx as possible

today. If it's not feasible in the short run, then the dependency tracking for document should be implemented.

Dima

--
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/CACLE5GCMPdFvRAt2QvC-jOZPfdOnJG%3DFbW-LaoQpjPU_s_k_7Q%40mail.gmail.com.

[Dima Pasechnik]

On Monday, September 29, 2025 at 11:12:49 AM UTC-5 John H Palmieri wrote:

On Monday, September 29, 2025 at 8:01:58 AM UTC-7 dim...@gmail.com wrote:

On Sun, Sep 28, 2025 at 10:52 AM Kwankyu Lee <ekwa...@gmail.com> wrote:
>
> On Friday, September 26, 2025 at 7:47:25 AM UTC+9 John H Palmieri wrote:
>
> Here are some recent occurrences in Sage development:
>
> 1. The documentation is not built by default.
>
>
> Previously "make" built doc. Now it doesn't. This change affects all developers using sage-the-distro.

And it is a positive change, as one does building of the code more
often than building of the code and the docs.

I understand that opinion, but it should have been discussed by the Sage community before being implemented.

 

 

> As such, It should have been announced in sage-devel. I don't know if it was.

And this is fine. You were not visibly doing anything Sage-related for
at least half a year, after a minor scandal,
with you demanding more "respect" legacy of a developer removed from
the project for major misconduct.

I don't know if I should read this as an attack on Kwankyu or a more general message, conveying something like, if you don't post here much,

I didn't write "post", don't put words in my mouse please. I meant "work", not post - and you know this.

We could be doing work instead of posting all this here now --- but thanks to Kwankyu we waste time in this quarrel.

While you were writing this, I was fixing an issue you raised, by the way:

https://github.com/sagemath/sage/pull/40922

 

if you are not very involved in Sage development, then you should not express your opinion here. Either way: good job! This is a great way to make the Sage community more open and welcoming! Thanks!

It's absolutely not what this is about, please stop making things up. Kwankyu was on his Sage sabbatical, after making a scandal about us not respecting the legacy of one past Sage contributor (that contributor has provided me with a real PTSD, and visibly more grey hair,  by the way). Then he came back, and oops, another scandal. Do you welcome scandals? I don't.

 

>
> 2. There has been the assertion that Conda is the recommended approach for compiling from source.
>
>
> This is a major change. This should be approved in sage-devel before it is officially adopted (appear in docs).

No, why? It's just how things are at the moment. Conda is the easiest
cross-platform way to install Sage, full stop.
It's hard to argue otherwise. If someone writes that 2+2==4 in the
manual, will you demand an approval for this too?

There is a difference between saying "conda seems to work best these days" and "conda is the recommended approach". The second version connotes that a person or people in authority have deemed this to be the case, and I don't think that has happened. (The only authority would come from a discussion and vote on sage-devel, given our current governance structure.) In contrast, the first version is clearly just an opinion of an individual poster.

I am sorry, this is just the famous "let's have a meeting instead of making a decision". Let's not write "2+2==4" anywhere because, you know, opinions vary,

in this economy in particular, let's have a meeting. A perfect way to waste an hour or two. 

What we should do first is to start from basics: figuring out what we're doing here; fix https://github.com/sagemath/sage/issues/36827

Because otherwise we just look silly.

Then, say, after 3 weeks from today, someone (I can do it) will make a PR based on the discussion, and the PR will go the usual way.

 

 

>
>
> 3. Kwankyu has brought up some issues about github release creation.
>
>
> We are keeping changelogs here: https://www.sagemath.org/changelogs/index.html. They are automatically generated by a few github workflows.
>
> To keep the format (contributions divided by releases) of the changelogs, I made the PR https://github.com/sagemath/sage/pull/39194.
>
> Recently https://github.com/sagemath/sage/pull/40709 removed the code from #39194 without any discussion.
>
> The author and the reviewer of #40709 made no efforts to fix the regression, as seen in https://github.com/sagemath/sage/pull/40840 and https://github.com/sagemath/sage/pull/40843.

#40709 was fixing a much much bigger regression than this.
https://github.com/sagemath/sage/pull/39194 solves a very minor (I
think non-existent, and I am going to put it to a vote here) issue in
a hard to maintain way.

CI tasks like one tackled in #40709 like this are hard to fix,
as you never know whether it will actually work when deployed in the
real, in this case while making a
new release.

Yes, there was a lot of CI code added, removed or redone lately. I
don't know why you have made such a fuss about your 20 lines.

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

Please stop making unfunded assumptions about someone being careless or not.
It's impossible to think about consequences of removing of something
that's broken and serves an unclear purpose, while its author
is not around. Note that it is about the CI code, which is as a rule
hardly ever documented.

If someone removes a line saying something like "from X import Y", then the author and reviewer should just do a quick search to see if Y is still used anywhere, rather than just leaving it as an undefined symbol. I think it's fair to call that careless.

 

And if someone's patch involves 100s of  "from X import Y" rearranged, added, or remove - as happens a lot with build system work at the moment -

would you also insist on manual checking of each and every changed import statement?

I'd call it getting work done, with given resources, on time. 

If someone is working on the build system and neither the author nor the reviewer think to try it out on a fresh git clone, I think it's also fair to call that careless.

When was the last time  you worked on the  build system? 

Why do you think everyone has gobs of time, and enough patience, to try every seemingly trivial change from a clean slate?

Our build system is still too slow for this.

In particular on Macs, where way too many packages have to be built. 

Why no Mac user is  working on this aspect, e.g. by creating Homebrew formulae to have more packages installable via brew?

It can be done for all non-Python projects, it's easier than it looks, Macaulay2 has done it for their major deps 

(we can reuse some of their formulae in https://github.com/Macaulay2/homebrew-tap)

Dima

[Dima Pasechnik]

On Monday, September 29, 2025 at 3:34:44 PM UTC-5 Nils Bruin wrote:

It seems to me there are two things that arise in conflict here:

 - some people who see, unannounced, big changes and failures happen.

 - developers who see certain changes as necessary to keep their maintenance burden manageable and other changes as desirable because there are benefits to be had.

The first group are not automatically opposed to the changes that the second group want. It's just that their first encounter with the changes is a negative one and therefore they react negatively.

If there had been a discussion about the proposed changes, it is very well possible that the consensus would have been that it's worth to make the change (that is mainly: embrace meson and/or, change when docs are built due to cost) and at the very least, after a course of action was converged on, people would have at least had some warning that instability in building was imminent due to some large changes being merged.

Whether "make all" builds docs, or not, isn't worth the time spent on discussing merits and demerits of it.

Sagelib build system has been reborn, mainly thanks to heroic efforts of Tobias, and it has been reborn this way. Perhaps it was my oversight,

as I reviewed a large chunk of that work. Mea culpa.

 

Autocratic rule by just forcing decisions through does not invite buy-in and ultimately will narrow the community; not grow it.

No, no autocratic decisions. The authority of the community to do various unpleasant plumbing and swamp draining on the system is, de facto, delegated to

whoever volunteers to get their hands dirty. The community normally appreciates the work done, and tolerates minor hiccups

which always arise. Certainly major hiccups cannot be tolerated, and that's OK. But hiccups like an unannounced change on whether or not

"make all" builds docs are truly minor. Aggrandizing minor hiccups is not welcomed by aforementioned volunteers, obviously.

Well, yes, you can complain that it's volunteers' dictatorships - but instead you can tell yourself that it's great that you didn't have to spend you precious time

on that plumbing assignment. An unpaid volunteer's labour of this sort is donation to the project (obviously there is no direct benefit to the volunteer here, as

it's not something interesting from scientific or engineering point of you)

  

  

It would probably help if we get a more well-defined governance structure in place for sagemath (mainly because it will help to still be able to act in situations where consensus cannot easily be reached) but we won't be able to avoid the discussion to see to what degree we can reach consensus. That step is necessary to maintain a welcoming community. I don't think sagemath is viable by running it as a collaboration of a small group of maintainers and release engineers. So we're stuck with the politics of making decisions in a large group of people.

The only real way to get any classical  governance is to get some funding, then one can organise around the grant, like it happened in  OpenDreamKit times.

(then at least some volunteers can get paid and thus be more thorough in their work).

Otherwise it's, as I explained above, a volunteers' dictatorship. Donate your labour, and rule with thus earned social capital.

Dima

[julian...@fsfe.org]

Hey there,

I am very grateful that people put their time into working on the build system, packaging, and these little developer annoyances. After some initial hiccups, it's been a joy to work with meson, not having the docs build all the time is imho the right thing to do, and installing with conda has proved much easier (and at the very least it fails much faster, at least when I am doing the hand-holding.) That's my personal experience and I understand that for others such changes might have been much more annoying.

Personally, I was not too surprised by any of these changes. Maybe because I happened to stumble upon the relevant PRs on GitHub before things were merged. But apparently that didn't work for many other people. I think it's a good idea to announce anything that is likely going to affect developers before it's merged. I don't think this means that everything that affects developers needs a vote but announcing things is a friendly gesture and if people then have doubts that this is the right way forward, we can still call for a vote.

On Monday, September 29, 2025 at 11:34:44 PM UTC+3 Nils Bruin wrote:

Autocratic rule by just forcing decisions through does not invite buy-in and ultimately will narrow the community; not grow it. 

I think a friendlier aspect would be to call this do-ocracy but of course I understand what you mean. Ultimately, many open source projects work to some extent like that. The project (by whatever governance) might decide on a direction but if nobody is willing to implement things, then such a decision doesn't really matter. Instead, when somebody is willing to improve things, I think the general attitude should be a supportive one. Of course people should invite buy-in and listen to criticism (and in our system this might ultimately lead to disputed PRs or a vote on sage-devel.)

On Monday, September 29, 2025 at 7:12:49 PM UTC+3 John H Palmieri wrote:

If someone is working on the build system and neither the author nor the reviewer think to try it out on a fresh git clone, I think it's also fair to call that careless.

Others may disagree with me.

Yes, I think I do disagree :) I would have expected the automated testing (buildbot) to catch such an issue somehow. I personally think it's too much to ask from a reviewer to try something like this. After all, what would have been thorough? Whether it builds from a git clone & from a tarball & from a previous build on Linux & macOS…then I'd rather not review to be honest. I don't have the changeset in front of me but I think it's a call for the author to make which scenarios to check (and I am sure the author checked some scenarios that they saw most likely affected.) When you make changes on the foundations, stuff breaks, people are sorry, and we move on. That's unfortunate but that's life. I think that's one of the main reasons for CI, i.e., to detect unexpected breakage.

julian

[Richard_L]

Regarding documentation, I would note that README.md on GitHub still says:

    "The HTML version of the documentation is built during the compilation process of Sage and resides in the directory local/share/doc/sage/html/. You may want to bookmark it in your browser."

That should be changed if no longer true, and instructions for generating docs provided.

As one whose focus is on using Sage, I look for coherence and stability, so that I can get on with the mathematics. I am disappointed when 'tan?' no longer produces the documentation for tan(). Please remember the users.

 - Richard

[Martin R]

why would `sage: tan?` no longer produce the documentation?  I must have missed something.

Martin

[Travis Scrimshaw]

I have always used the "make build" option to avoid the docbuilds. That is what I have told people previously when they are first starting out with development too. Perhaps we haven't been advertising as well as we should have about this. In either case, making things more transparent and with a concise description (with links to longer pages of text) would help with this I feel.

Best,

Travis

[Dima Pasechnik]

On September 30, 2025 9:31:42 AM CDT, Richard_L <Rich...@lozestech.com> wrote:

Regarding documentation, I would note that README.md on GitHub still says:

    "The HTML version of the documentation is built during the compilation process of Sage and resides in the directory local/share/doc/sage/html/. You may want to bookmark it in your browser."

That should be changed if no longer true, and instructions for generating docs provided.

What branch of Sage are you referring to? The default, i.e. the develop branch?

If so, it's not official, not ready for any serious use, it's a half-finished product.

The Readme has not really been touched since the 10.7 release; one can see the difference with the 10.7 version

by running "git diff 10.7 README.md".

Its contents, hopefully, correctly reflect what's in 10.7, which predates the changes discussed now.

As one whose focus is on using Sage, I look for coherence and stability, so that I can get on with the mathematics. I am disappointed when 'tan?' no longer produces the documentation for tan(). Please remember the users.

Using an unreleased version comes with absolutely no promise of any attempt at coherence.

Dima

[Nils Bruin]

On Monday, 29 September 2025 at 23:17:06 UTC-7 dim...@gmail.com wrote:

Well, yes, you can complain that it's volunteers' dictatorships - but instead you can tell yourself that it's great that you didn't have to spend you precious time

on that plumbing assignment. An unpaid volunteer's labour of this sort is donation to the project (obviously there is no direct benefit to the volunteer here, as

it's not something interesting from scientific or engineering point of you)

I don't dispute that the sagemath build process needed maintenance/modernisation work because bitrot is a real thing -- and as Orlitzky points out, it happens by itself. I'm not doubting that your intent is to make sage really better.

I think the plumbing analogy can do a little more work here: it may very well be that the sewage main in your street needs replacement. That's maintenance that needs to happen every few decades. But if the trucks show up one morning unannounced and break open the street and block the driveway, most people will be annoyed at least. Quite a few would be livid. And that's not how that kind of work generally happens. Instead, people receive information about what is going to happen, why it is going to happen, and what they can do to mitigate the impact.

The exact actions would be different here, but the same principles apply: if people are informed beforehand about the work, its necessity and the benefits, it is much easier for them to accept and plan around the inconveniences of construction.

 

The only real way to get any classical  governance is to get some funding, then one can organise around the grant, like it happened in  OpenDreamKit times.

(then at least some volunteers can get paid and thus be more thorough in their work).

Otherwise it's, as I explained above, a volunteers' dictatorship. Donate your labour, and rule with thus earned social capital.

Time spent on improving sage can definitely earn "social" capital. It does require that many in the community *perceive* your contributions as improving sage, though. So I think it is also in the interest of the developer/maintainer who wants to earn social capital in order to be able to influence decisions in sage, to try and get buy-in from many community members: it will improve trust in their judgement to make changes to sage that are beneficial. Trust is an important component of social capital.

 

[John H Palmieri]

I build and test almost every new Sage release, and I have been doing this for years.

 

Why do you think everyone has gobs of time, and enough patience, to try every seemingly trivial change from a clean slate?

Our build system is still too slow for this.

In particular on Macs, where way too many packages have to be built.  

Why no Mac user is  working on this aspect, e.g. by creating Homebrew formulae to have more packages installable via brew?

It can be done for all non-Python projects, it's easier than it looks, Macaulay2 has done it for their major deps 

(we can reuse some of their formulae in https://github.com/Macaulay2/homebrew-tap)

If you want people to be more involved in the build system, ask them. Here is a suggestion: open a new thread on sage-devel in which you describe the changes you (not just you, Dima, but everyone involved in the recent changes to the build system) have made, you are making, you want to make. Explain why you want to make them, the benefits and downsides as compared to the current/previous system, as compared to other alternatives. Try to persuade people that these are good things to work on. Perhaps accept constructive criticism and modify plans, if someone has good suggestions. Then describe ways that people can help, both big and small. And then provide updates every now and then: what has been accomplished since the previous update, what still needs doing, what is urgent, what can wait, etc.

[Dima Pasechnik]

On Tue, Sep 30, 2025 at 12:56 PM Nils Bruin <nbr...@sfu.ca> wrote:

On Monday, 29 September 2025 at 23:17:06 UTC-7 dim...@gmail.com wrote:

Well, yes, you can complain that it's volunteers' dictatorships - but instead you can tell yourself that it's great that you didn't have to spend you precious time

on that plumbing assignment. An unpaid volunteer's labour of this sort is donation to the project (obviously there is no direct benefit to the volunteer here, as

it's not something interesting from scientific or engineering point of you)

I don't dispute that the sagemath build process needed maintenance/modernisation work because bitrot is a real thing -- and as Orlitzky points out, it happens by itself. I'm not doubting that your intent is to make sage really better.

I think the plumbing analogy can do a little more work here: it may very well be that the sewage main in your street needs replacement. That's maintenance that needs to happen every few decades.

Our  "sewer" has been leaking and blocking, for years, has broken all  the sanitary standards, etc.

Finally someone people got fed up with the stink and stuff coming up the WC now and then,

and have fixed it, at a serious personal. 

Surely in the process a lot of extra stink has been released, but it's temporary.

And the "information" and "leaflets" explaining the situation had been there for everyone to see, for years. 

 

But if the trucks show up one morning unannounced and break open the street and block the driveway, most people will be annoyed at least. Quite a few would be livid. And that's not how that kind of work generally happens. Instead, people receive information about what is going to happen, why it is going to happen, and what they can do to mitigate the impact.

The exact actions would be different here, but the same principles apply: if people are informed beforehand about the work, its necessity and the benefits, it is much easier for them to accept and plan around the inconveniences of construction.

 

The only real way to get any classical  governance is to get some funding, then one can organise around the grant, like it happened in  OpenDreamKit times.

(then at least some volunteers can get paid and thus be more thorough in their work).

Otherwise it's, as I explained above, a volunteers' dictatorship. Donate your labour, and rule with thus earned social capital.

Time spent on improving sage can definitely earn "social" capital. It does require that many in the community *perceive* your contributions as improving sage, though. So I think it is also in the interest of the developer/maintainer who wants to earn social capital in order to be able to influence decisions in sage, to try and get buy-in from many community members: it will improve trust in their judgement to make changes to sage that are beneficial. Trust is an important component of social capital.

There is a very small and very vocal minority which views the recent changes negatively.

They even go around and throw sand into mechanical part of the equipment used to put finishing touches on the much better sewer.

They apparently are missing the old stink and stoppages, and they shout that the new construction had been carried out

in a careless way. 

It's good that we hear voices telling this minority to stop.

Yours,

Dima, a full-stack plumber

 

 

--
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/f4871539-adb8-48a9-83c9-e737c7a7e477n%40googlegroups.com.

[kcrisman]

No, no autocratic decisions. The authority of the community to do various unpleasant plumbing and swamp draining on the system is, de facto, delegated to

whoever volunteers to get their hands dirty. The community normally appreciates the work done, and tolerates minor hiccups

which always arise. Certainly major hiccups cannot be tolerated, and that's OK. But hiccups like an unannounced change on whether or not

"make all" builds docs are truly minor. Aggrandizing minor hiccups is not welcomed by aforementioned volunteers, obviously.

Well, yes, you can complain that it's volunteers' dictatorships - but instead you can tell yourself that it's great that you didn't have to spend you precious time

on that plumbing assignment. An unpaid volunteer's labour of this sort is donation to the project (obviously there is no direct benefit to the volunteer here, as

it's not something interesting from scientific or engineering point of you)

Unfortunately, that is precisely the argument that was made (namely, whoever is doing the work gets ownership) with some other design decisions that other people disagreed with. Words similar to autocratic were used with respect to those decisions, perhaps ironically, perhaps just sadly.  Inevitably, the sewer analogy breaks down on both sides (though I am very impressed by several contributions to it in this thread!), because here the users may also be developers and vice versa, and more importantly there are the *end users* who are, in some sense, not represented by the analogy at all.

Or, to continue it inappropriately, they want a usable sewer, but might be confused when they are told they need to first switch all their home interior plumbing to PEX because copper is overhauled.  (Please no one compare any OS with lead plumbing ...)

In any case, this argument might cut too many ways to use it without some substantial nuance.

  

It would probably help if we get a more well-defined governance structure in place for sagemath (mainly because it will help to still be able to act in situations where consensus cannot easily be reached) but we won't be able to avoid the discussion to see to what degree we can reach consensus. That step is necessary to maintain a welcoming community. I don't think sagemath is viable by running it as a collaboration of a small group of maintainers and release engineers. So we're stuck with the politics of making decisions in a large group of people.

The only real way to get any classical  governance is to get some funding, then one can organise around the grant, like it happened in  OpenDreamKit times.

(then at least some volunteers can get paid and thus be more thorough in their work).

Otherwise it's, as I explained above, a volunteers' dictatorship. Donate your labour, and rule with thus earned social capital.

That is a classic "Raymondian" argument, of course, and has a lot of value.  But where it does break down is when other volunteers are discouraged from contributing (not necessarily to the same components, of course) because of disagreements around this.  Anecdotally in the governance meetings (which did bring up OpenDreamKit), it is a significant factor in "people" (which is intended to mean a wide variety of Sage contributors, not including some of the most active, or previously most active, ones) just getting on with their mathematics.

And in particular there was a recognition that we do need people with software engineering expertise, so that's not at all to downplay the contributions to the build system being discussed.  But I do think it's more than a "vocal minority" who are, perhaps not viewing all recent changes negatively, but are at least confused as to whether they are all more necessary than trying to maintain that overall community in so doing.  This discussion makes it clear that such confusion exists, and I believe it should be taken seriously.

[Tobia...@gmx.de]

On Tuesday, September 30, 2025 at 7:29:28 PM UTC+8 julian...@fsfe.org wrote:

I am very grateful that people put their time into working on the build system, packaging, and these little developer annoyances. After some initial hiccups, it's been a joy to work with meson, not having the docs build all the time is imho the right thing to do, and installing with conda has proved much easier (and at the very least it fails much faster, at least when I am doing the hand-holding.) That's my personal experience and I understand that for others such changes might have been much more annoying.

Thanks a lot, Julian, for the encouraging words—they really mean a lot. I’m glad the changes are working out for you.

[Tobia...@gmx.de]

Taking it as a personal learning opportunity, I had a look at how the meson migration was handled at scipy and numpy. Both had quite detailed GH issues outlining the general plan, and an elaborated motivation (in the case of scipy):

- https://github.com/scipy/scipy/issues/13615

- https://github.com/numpy/numpy/issues/22546

In contrast, our https://github.com/sagemath/sage/issues/34630 and https://github.com/sagemath/sage/issues/38880 are focused more on the concrete implementation details & technical steps, not the bigger picture.

I couldn't find any scipy mailing list announcements concerning the meson transitioning (except for https://mail.python.org/archives/list/scip...@python.org/message/4S43BYHDQIPQENNJ6EMQY5QZDZK3ZT5I/, which is about funding of parts of that project). For numpy, the idea + plan was announced at https://mail.python.org/archives/list/numpy-di...@python.org/message/K3JJJBUJSZYRPHLJX64X3U5JNQESODQR/, and after most of it was merged into main an update was given in https://mail.python.org/archives/list/numpy-di...@python.org/message/NQZE6SPXFJGXP5ZDXCBCCOTM2JDV2HHV/.

[John H Palmieri]

I think that building from a fresh git clone is not an unreasonable thing to expect a careful reviewer and author to do. It's certainly something I do if I'm testing a change that affects the build system. This is especially the case for the particular situation here: the PR deleted a filed called, I don't know, blah.py.in or something. If you are doing an incremental build, the file blah.py will likely already be present from a previous build, so maybe the only way to see an impact of this change is to build from a fresh clone. (Does "make distclean" remove all of these autogenerated files? I don't think so, but I'm not sure.) I would also say that a careful reviewer will absolutely use the automated testing framework, but they will also know that this framework has its limitations.

 

julian

[Dima Pasechnik]

Even on a fast machine with most packages pre-installed system-wide (running e.g. Gentoo Linux),

cleaning the repo,

configuring  with `--enable-system-site-packages`, and build+tests+docbuild still takes ~1.5 hours (longer if you do long tests, have lots of optional packages, etc).

Another hour if  `--enable-system-site-packages` is not used. Another hour or 2 if you updated something that a lot is relying on, e.g. flint,

and have to build many big packages, like Singular.

So, assuming you don't review more than 1 PR in parallel, it can easily take 2-3 hours on average.

OK, I often review seemingly unrelated PRs in parallel. And yes, I often don't test in such a throughout way something that, seemingly,

is not potentially breaking things (but then, well, indeed, a silly typo can break things far down, in a test, or in docbuild).

Docbuild is a major drag, it needs to get dependency tracking to avoid rebuilding the whole thing.

By the way, to give you an example of careless, in my book, reviewing: #40877.

(it wasn't actually even reviewed, the release manager just pushed it through, over our protests).

It reverted #40765, which in particular made sure that there is a way to find

Sage's cython directories, via sage.config. Now for instance sage_numerical_backends_* (coin, etc) cannot be built because the old way to find cython

directories is gone, and the new way got reverted.

So now, there is a request to revive sage_numerical_backends_coin, and one has to dig through the branch of #40765 to fish out the necessary bits. 

Dima

 

julian

--
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/58dee9b6-ec90-4e4a-ae7c-0d4f055e0777n%40googlegroups.com.

[Marc Culler]

On Thursday, October 2, 2025 at 1:50:37 PM UTC-5 dim...@gmail.com wrote:

By the way, to give you an example of careless, in my book, reviewing: #40877.

(it wasn't actually even reviewed, the release manager just pushed it through, over our protests).

It reverted #40765, which in particular made sure that there is a way to find

Sage's cython directories, via sage.config. Now for instance sage_numerical_backends_* (coin, etc) cannot be built because the old way to find cython

directories is gone, and the new way got reverted.

So now, there is a request to revive sage_numerical_backends_coin, and one has to dig through the branch of #40765 to fish out the necessary bits. 

I don't know what this about  I was able to build sage_numerical_backends_coin with no problems by doing what I suggested in my email.  Namely:

    replace the symlink sage/build/pkgs/sage_numerical_backends_coin/package-versiion.txt -> ../../../VERSION.txt by a file containing one line: 10.4

With the symlink the upstream url is for a tatball with version number 10.8beta5 which of course does not exist since the latest version on pypi is 10.4.

Once the tarball is downloaded the package builds fine and can be inported into sage.

- Marc

[Dima Pasechnik]

This doesn't work for me (maybe it does on non-editable installs, or with some other hacks like setting environment variables etc)
and anyway this used an outdated and soon to be removed way to get the headers.

So here is a proper fix: <https://github.com/sagemath/sage/pull/40964>

Please review

[Volker Braun]

On Thursday, October 2, 2025 at 7:14:56 PM UTC+2 John H Palmieri wrote:

Does "make distclean" remove all of these autogenerated files? 

It should, but its possible that something was missed.

To be totally sure you can run e.g. git clean -f -d -x -e upstream .

 

[Antonio Rojas]

Isn't sage_numerical_backends_coin superseded by the properly maintained cvxpy backend included in sage itself (which can use coin in the background, among many other solvers)? Is there any reason to keep maintaining this at all?

[John H Palmieri]

I think a priority should be making sure that Sage builds, so just get a fresh git clone and run 'make build'. That might take under half an hour depending on the machine and how many system packages get used, so even less time if building will actually fail.

[Dima Pasechnik]

On Fri, Oct 3, 2025 at 12:08 PM John H Palmieri <jhpalm...@gmail.com> wrote:

I think a priority should be making sure that Sage builds, so just get a fresh git clone and run 'make build'. That might take under half an hour depending on the machine and how many system packages get used, so even less time if building will actually fail.

 

Run "make" nowadays, yes :-) Under half an hour on Gentoo with everything installed, yes. Several times longer on macOS, where everything dependent on openblas must be built, most Python packages must be built, GAP and eventually its packages must be built, etc. 

A part of the price you pay for demanding that every PR builds and doesn't break any relevant test is

that some changes need to be done as huge patchbombs, of which

#39030 is a prime example (81 commits, 200+ files touched, etc). 

I probably fully built it 30 or more times as a reviewer (and a minor contributor).

And it took much longer than it would have been if it was done in pieces, some of them resulting in broken builds in corner cases or on

some platforms.

 

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/e302dfd4-f764-4e4c-a109-b5da4b4d893dn%40googlegroups.com.