In my case, most of our computers run Fedora (for desktops) and Rocky/Redhat for servers. So on the guide I end up with "other distributions" and then "Conda".
The problem there at the moment for me is that it punts to "conda" documentation for how to get conda set up -- and conda seems very insistent on messing with my ".bashrc". I don't want that! Particularly because if another user tries to run the sage install, they would not have those modifications to their shell environment. And also because I don't particularly want conda to mess with my startup scripts: I'm just setting up conda to run sage; not because I want to do anything else with it. In fact, since I'd probably just have a normal git-based install for development I would really want there to be *no* traces of the conda environment unless I specifically enter a subshell to have that environment. I'm not sure that "pip install" without shielding from system upgrades will be reliable enough, but it's worth a try. For conda it does seem the case that once the conda install is in place, just executing the ".../sage" script living in its subtree (without activating conda) does initialize enough of the environment to get sage running, so that might be an option if we can somehow find out if that is robust enough. On Monday, 9 February 2026 at 08:48:48 UTC-8 [email protected] wrote: > 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/89eb73be-b516-429b-aea7-446a3bf74a4bn%40googlegroups.com.
