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..
El jueves, 4 de septiembre de 2025 a las 17:34:32 UTC+2, Dima Pasechnik escribió: > On Wed, Sep 3, 2025 at 6:34 PM Kwankyu Lee <[email protected]> wrote: > > > > On Wednesday, September 3, 2025 at 8:55:01 PM UTC+9 [email protected] > 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 > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-release/c8ce24b4-0d35-4807-a0fe-11bda4d11782n%40googlegroups.com.
