In this PR (https://github.com/sagemath/sage/pull/35585), the three optional packagesinfo, valgrind, rubiks are switched from our custom installation scripts to a (binary) installation from conda-forge.
This drops platform support for 32-bit Linux (see https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help) for these optional packages. We will need a decision if this OK. A precedent for phasing out support for a platform in this way was set in 2021 (Sage 9.4), when we dropped support for optional packages on old Linux systems with GCC 4.x toolchains (https://wiki.sagemath.org/ReleaseTours/sage-9.4#Support_for_optional_packages_on_systems_with_gcc_4.x_dropped). On Saturday, April 29, 2023 at 12:28:22 AM UTC-7 Matthias Koeppe wrote: > That's now https://github.com/sagemath/sage/pull/35585 (needs review); > starting with optional packages, not standard infrastructure packages > though. > > > On Saturday, April 29, 2023 at 12:14:56 AM UTC-7 Volker Braun wrote: > >> +1 to just using conda for all basic infrastructure packages if the host >> doesn't have them. Just put a conda env in the PATH and done. >> >> In my experience these work really well. I've only gotten issues with >> conda when you veer off the trodden path too much, e.g. I've had nothing >> but trouble installing ruby from conda-forge and then trying to build gems >> on top of that (ruby has various hard-coded compiler configuration paths, >> some of which point to the wrong place). >> >> >> On Saturday, April 29, 2023 at 1:25:26 AM UTC+2 Matthias Koeppe wrote: >> >>> On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote: >>> >>> The next in line will be jupyter and friends. >>> >>> >>> I agree with this point; specifically the front-end parts of >>> Jupyter/JupyterLab, which run in a separate Python process (and therefore >>> can be installed in a completely separate tree / venv). For this idea, we >>> have the the long-open metaticket >>> https://github.com/sagemath/sage/issues/30306 >>> >>> But this observation can be generalized. >>> >>> For any package from which we only use executables or data, not a shared >>> library, we can install it in any way we want -- without compromising the >>> Sage distribution's ability to use already installed system packages. >>> So we can switch from our own installation scripts to using conda-forge >>> for these! >>> >>> I've written up the details in >>> https://github.com/sagemath/sage/issues/35583 >>> >>> I'm counting about 40 packages (not counting the Jupyter frontend >>> components) for which we can make a safe and easy withdrawal from packaging >>> activities, WITHOUT making the Sage distribution harder to install, and >>> avoiding the "concave cost" along the path that I mentioned. >>> >>> (Note that gcc/gfortran do not fall into this category of packages >>> because of their runtime library components.) >>> >>> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f0505a52-a005-492f-b7c7-c9a92b69192an%40googlegroups.com.
