On February 9, 2026 4:05:44 PM CST, Nils Bruin <[email protected]> wrote:
>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"
I tried to make docs less conda-centric in
<https://github.com/sagemath/sage/pull/41527>
should be in the next beta
>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/E02CC91A-94A0-4C04-BC00-2EA71DC1E366%40gmail.com.
