Remove Python3 and some dependencies

[cxzhong]

1. Delete python3 and sqlite packages. as @dimpase suggested, we do not provide python3 package.
2. fix the ncurses compilation problem. It is caused by The C++ part is not maintained and it is unused for mostly all cases. So we directly do not compile the C++ part.
3. fix the readline package can not be built in gcc15. remove the outdate patch.
4. building sage in high parallel threads may result error. When the sagelib started building, the maxima is still building. It will cause sagelib can not proper find the location of maxima. Just add maxima as a dependency of sagelib.
5. fix the CI, because we remove python package.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit ab7c4d7; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[orlitzky]

I am officially retiring from supporting the things in build/pkgs, sorry :)

The changes look OK to me, only the --no-as-needed is a bit suspicious because --as-needed is default on Gentoo and we don't have any workarounds for it in readline.

[dimpase]

the best way here is to remove Python package from the distro. It has about 1 user, who easily can do without it, too.

[cxzhong]

the best way here is to remove Python package from the distro. It has about 1 user, who easily can do without it, too.

It will break minimal linux CI. for minimal building, it needs python package. How to deal with this problem. and we can not test the building of such basic packages like readline ncurses and so on

[dimpase]

please see cxzhong#15

[dimpase]

I'll stop for the day (it's 22:20 local time). We still need to sort out PYTHON in makefiles, there is some spaghetti code with it, as it's meant to be rebuilding python3 now and then, in a special way.

And there is also sage-bootstrap-python, which should be set to the python3 we're getting anyway from the system.

[cxzhong]

I'll stop for the day (it's 22:20 local time). We still need to sort out PYTHON in makefiles, there is some spaghetti code with it, as it's meant to be rebuilding python3 now and then, in a special way.

And there is also sage-bootstrap-python, which should be set to the python3 we're getting anyway from the system.

OK, thank you very much

[dimpase]

@tobiasdiez - do you know if here we could simply rename sage-bootstrap-python -> python3, and get rid of it?

[tobiasdiez]

@tobiasdiez - do you know if here we could simply rename sage-bootstrap-python -> python3, and get rid of it?

I don't know for sure, but would assume yes. If you now require a recent-enough python, sage-bootstrap-python would still refer to the python that was used to start the build process (I assume), even if you later activate the sage-venv (which contains its own python that is invoked by python3). That distinction might be helpful in a scenario where sage-venv is not working properly for some reason and you want to rebuild it. But then again, users can just delete the sage-venv in this case and start over.

[dimpase]

removing $(PYTHON) was not a good idea. It broke creation of the venv

[dimpase]

I have fixed cxzhong#15 - can you merge it here?

[cxzhong]

[primecountpy-0.2.1]   [spkg-install] ERROR: Cmake subproject primecount is buildable: NO
 [primecountpy-0.2.1]   [spkg-install] 
 [primecountpy-0.2.1]   [spkg-install] ../meson.build:23:26: ERROR: Automatic wrap-based subproject downloading is disabled
 [primecountpy-0.2.1]   [spkg-install] 
 [primecountpy-0.2.1]   [spkg-install] A full log can be found at /sage/local/var/lib/sage/venv-python3.13/var/tmp/sage/build/primecountpy-0.2.1/src/.mesonpy-8ng_oekv/meson-logs/meson-log.txt
 [primecountpy-0.2.1]   [spkg-install] 
 [primecountpy-0.2.1]   [spkg-install] ERROR Backend subprocess exited when trying to invoke build_wheel
 [primecountpy-0.2.1]   [spkg-install] ********************************************************************************
 [primecountpy-0.2.1]   [spkg-install] Error building a wheel for primecountpy-0.2.1

[cxzhong]

Ubuntu package of libprimecount-dev has no version in pc file

[cxzhong]

This is because Ubuntu/Debian package is broken. I have report to Debian

[dimpase]

Ubuntu package of libprimecount-dev has no version in pc file

there was a bug in recent primecount and primesieve versions that resulted in this

meanwhile the (primecount/sieve) upstream has released new versions with a fix

[dimpase]

we need a blurb about installing python3 and xz/liblzma from source, to be put into build/pkgs/_bootstrap/SPKG.rst, akin to what we have for Boost etc in build/pkgs/_prereq/SPKG.rst

[dimpase]

I think it's also possible to build sage-distro using a uv-installed Python, in a venv.

[dimpase]

no, this is incorrect. A modern xz/liblzma installs liblzma.pc file, and ./configure checks for then using a pkg-config macro. Thus, to detect xz/liblzma at a non-standard location, add
it to PKG_CONFIG_PATH, i.e. export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:<prefix used>/lib/pkgconfig

[dimpase]

with an external python, I am getting

[sagelib-10.9.beta6] [spkg-install] Successfully built sagemath
[sagelib-10.9.beta6] [spkg-install] Installing collected packages: sagemath
[sagelib-10.9.beta6] [spkg-install]   changing mode of /home/dima/software/tmp/py/python/bin/sage to 755
[sagelib-10.9.beta6] [spkg-install] Successfully installed sagemath-10.9b6
[sagelib-10.9.beta6] [spkg-install] /home/dima/software/tmp/py/python/bin/jupyter-kernelspec:5: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguous
[sagelib-10.9.beta6] [spkg-install] and fails to parse leap day. The default behavior will change in Python 3.15
[sagelib-10.9.beta6] [spkg-install] to either always raise an exception or to use a different default year (TBD).
[sagelib-10.9.beta6] [spkg-install] To avoid trouble, add a specific year to the input & format.
[sagelib-10.9.beta6] [spkg-install] See https://github.com/python/cpython/issues/70647.
[sagelib-10.9.beta6] [spkg-install]   from jupyter_client.kernelspecapp import KernelSpecApp
[sagelib-10.9.beta6] [spkg-install] [InstallKernelSpec] Removing existing kernelspec in /home/dima/.local/share/jupyter/kernels/sagemath
[sagelib-10.9.beta6] [spkg-install] [InstallKernelSpec] Installed kernelspec sagemath in /home/dima/.local/share/jupyter/kernels/sagemath
[sagelib-10.9.beta6] [spkg-install] touch: cannot touch '/home/dima/software/sage-src/local/var/lib/sage/venv-python3.14/bin/sage': No such file or directory

Easy to patch

--- a/build/pkgs/sagelib/spkg-install.in
+++ b/build/pkgs/sagelib/spkg-install.in
@@ -86,4 +86,4 @@ python3 -c 'import pathlib; from sage.misc.lazy_import_cache import get_cache_fi
 rm -rf build/temp.*
 
 # indicate that we are done - is needed to allow ./sage to start
-touch $SAGE_VENV/bin/sage
+touch $SAGE_VENV/bin/sage || true

and tests pass, ./sage runs as it should, etc.

@tobiasdiez - do you have an idea why there is no sage at that location (in fact there is no $SAGE_VENV/bin/) ?

I took a standalone Python install from https://github.com/astral-sh/python-build-standalone
then did python3 -m pip install setuptools
and passed it with ./configure --with-python=...

Should we pass --with-sage-venv=... in such cases, maybe? Or this is for a different scenario?

[tobiasdiez]

in fact there is no $SAGE_VENV/bin/

Sorry, no idea. Did you create a venv manually, or is then handled by sage-the-distro? Maybe something went wrong there.

+touch $SAGE_VENV/bin/sage || true

I kind of remember that we (you?) added this line already as a kind-of-hack in #39030. Maybe this is just no longer necessary when you use an external python?

[dimpase]

I am trying to come up with a reasonable advice for a manual installation of an external python. For reasons I don't understand, an external python as above doesn't behave in the same way as a system python - for the latter touch passes.

[dimpase]

with the official CPython Python on X86_64 (and maybe on arm64 too) macOS doesn't quite fly, as it's multiarch, and setuptools/cython gets confused as hell

src/bin/sage -t --warn-long 5.0 --random-seed=55326054598744560019782194678991778662 src/sage/env.py
**********************************************************************
File "src/sage/env.py", line 366, in sage.env.cython_aliases
Failed example:
    cython(                                               # optional - sage.misc.cython
    '''
    #distutils: extra_compile_args = OPENMP_CFLAGS
    #distutils: extra_link_args = OPENMP_LDFLAGS
    from cython.parallel import prange

    cdef int i
    cdef int n = 30
    cdef int sum = 0

    for i in prange(n, num_threads=4, nogil=True):
        sum += i

    print(sum)
    ''')
Expected:
    435
Got:
    ld: warning: ignoring file '/usr/local/lib/libgsl.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/usr/local/lib/libgmpxx.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/usr/local/lib/libmpfr.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/usr/local/lib/libgmp.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/Users/dima/software/sage/local/lib/libec.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/usr/local/lib/libpari.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/usr/local/opt/libomp/lib/libomp.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: ignoring file '/usr/local/opt/ntl/lib/libntl.dylib': found architecture 'x86_64', required architecture 'arm64'
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/mpfr/lib/libmpfr.6.dylib' which was built for newer version 15.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/gmp/lib/libgmp.10.dylib' which was built for newer version 14.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/gmp/lib/libgmpxx.4.dylib' which was built for newer version 14.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/pari/lib/libpari-gmp-tls.dylib' which was built for newer version 15.0
    ld: warning: building for macOS-10.15, but linking with dylib '/Users/dima/software/sage/local/lib/libec.14.dylib' which was built for newer version 15.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/gsl/lib/libgsl.28.dylib' which was built for newer version 14.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/ntl/lib/libntl.45.dylib' which was built for newer version 14.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/libomp/lib/libomp.dylib' which was built for newer version 14.0
    435
**********************************************************************
1 item had failures:
   1 of   7 in sage.env.cython_aliases
    [37 tests, 1 failure, 3.50s wall]

[dimpase]

here I'm still looking for a good easy way to install an external Python which works well with Sage.
The problem is, as usual, on macOS. The https://github.com/astral-sh/python-build-standalone ones have some loose things, leading to setuptools Cython module build spitting out warnings like

    ld: warning: search path 'Modules/_hacl' not found
    ld: warning: search path '/install/lib' not found
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/mpfr/lib/libmpfr.6.dylib' which was built for newer version 15.0
    ld: warning: building for macOS-10.15, but linking with dylib '/usr/local/opt/gmp/lib/libgmp.10.dylib' which was built for newer version 14.0

(the 1st two are probably a bug. The rest might be due to some weird switch in CFLAGS they use)

The python.org python is multiarch, which in such a case is just broken: #41120 (comment)

[dimpase]

@cxzhong - could you rebase?

[tobiasdiez]

here I'm still looking for a good easy way to install an external Python which works well with Sage.
The problem is, as usual, on macOS. The https://github.com/astral-sh/python-build-standalone ones have some loose things, leading to setuptools Cython module build spitting out warnings like

Honestly, if you recommend people to install the python builds from astral, you can also just tell them to run (or do it for them): uv sync, which also installs all Python packages. Then you also don't have to fight any Cython + setuptools issues. I know... that would probably be a too huge step.

[dimpase]

we are still dealing with the non-Python dependencies needed somehow, and this is not what's available externally, save for relatively rare Linux distros, and Conda.

[tobiasdiez]

Sure, you need to provide exactly the external dependencies of sagelib. Restricting the scope of sage-the-distro to those 20 packages or so would make a lot of sense to me.

Sorry for the tangential, back to the actual issue. What package still needs to build with setuptools, i.e where exactly do you get those issues with the astral python?

[dimpase]

where exactly do you get those issues with the astral python?

packages all build, it's tests related to the %% cython magic which fail due to noise emitted by the linker on macOS.
Stuff to do with macos deployment target, due to weird flags in its sysconfig.

[tobiasdiez]

Ah okay. Could you not filter out these (unimportant) warnings during the call of cython?