I agree! The install instructions at https://doc.sagemath.org/html/en/installation/index.html also seem to be in the spirit that you recommend. What would you still change there? Note that sage-the-distro (or any other building from source) is only recommended for developers that want to work _on_ sage.
I hope in the not so far feature, we could just provide binary wheels (bundling all deps), so that a simple `pip install sagemath` works on most systems. It would also be nice to have up-to-date releases for ubuntu/debian/fedora/homebrew. So if anyone has connections to package maintainers there, please ask for their support (I'm happy to help in case of any meson build problems). On Sunday, February 8, 2026 at 9:41:42 PM UTC+1 Nils Bruin wrote: > On Sunday, 8 February 2026 at 11:17:21 UTC-8 [email protected] wrote: > > [...] I would recommend a full rebuild of sagemath after updating any > dependencies. > > > I think we need some different ways to install sage then and document > them. Obviously, an ideal answer would be "just install the standard > package for sage from your distribution" but then we need that sage is > packaged for all/most distributions and that those packages are kept > reasonably up-to-date. Neither is true at the moment. Even if that is going > to be true in the future we still need an interim solution to bridge the > time in between. > > The kind of instructions I'm thinking about would be ones that are > acceptable for a mildly competent sysadmin who is maintaining, say, a slew > of VMs that people access for their general computing needs. They may well > configure those to regularly run auto-updates on. I'm not so sure they'd > be willing to install custom post-update scripts. > > It's probably somewhat acceptable for developers (like you and to some > extent me) to recompile sage after an update (note that you'll generally > not know for sure that a *dependency* for sage has been updated because > that's hidden in a list of 500 packages that are getting updated), but it's > far outside the normal experience for outside software like magma, maple, > matlab, google-chrome, etc: one installs them on a linux system and system > updates don't end up touching the install (usually in "/opt" somewhere) and > it keeps running fine. > > Does a non-editable install from source fare better for this? (sure, an > ABI-breaking upgrade would be a problem, but perhaps those don't happen so > much?) Perhaps that needs to be documented a little more prominently then? > > Conda seems to do a reasonable job (and even seems to provide binaries!). > Can we have a guide written up for a sysadmin to install sage using conda > in such a way that the users don't need to mess with conda themselves? I > think that just involves a shim script that sets up the conda environment > without relying on the user shell to do that. Perhaps some > AppImage/flatpak/... builds? Those tend to have their own kinds of breakage > but perhaps that can be avoided. > > I understand the push to disentangle sage-the-library and > sage-the-distribution, but sage-the-library still needs to be distributed > and I suspect we'll need to do that ourselves at least until enough > distributions agree to do it for us. > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/bd8d3338-7f27-4f50-9abc-58373360cfd6n%40googlegroups.com.
