Enable sage backend by default only if SAGE_ROOT is set #466
Conversation
It's possible to install the Sage system as a normal Python package, as e.g. in Fedora/Debian. In this case, presence of `sage.all` is not an indicator whether the user is running Sage, and checking for 'SAGE_ROOT' is more reliable.
|
Seems OK. The |
|
That was fairly silly as reasoning. System sage like sage-on-gentoo use system mpmath in their system sage. This change breaks the use of mpmath in a system install of sage. I'll admit that automated back end choice is a bit of an issue. But this change leads to this kind of stuff in sage-on-gentoo |
|
Is there a related upstream issue as reference? |
|
If by upstream you mean sagemath, then no. We have just stumbled across this in sage-on-gentoo yesterday cschwan/sage-on-gentoo#628. I think this change assumed that a system sage like the one shipped with fedora or debian is bringing a private copy of mpmath. This is not the case for Gentoo and I assume arch. |
|
It looks like I can get away with it by setting MPMATH_SAGE=1 rather then SAGE_ROOT. May be we should have some change in sage upstream to make sure MPMATH_SAGE is set when calling mpmath. While I want to make sure you are aware that the SAGE_ROOT assumption was simplistic, something probably needs to be done inside sage as well. |
|
I agree with this change in principle. Sage itself should be responsible for "enabling" sage mode when it imports mpmath (only I don't know if an environment variable is the right way to go about that, which is why I say "in principle"). It is also possible to install Sage using conda-forge, and the exact same problem exists there. If you install Sage into a conda environment, a ton of SymPy tests start failing, because they do not work properly when mpmath uses the Sage backend (I haven't investigated these tests so I can't say if they are legitimate bugs or just small numerical differences). Here is the upstream issue https://trac.sagemath.org/ticket/25445 (see also sympy/sympy#14703). Ideally, mpmath could use both backends at the same time, by switching out a context at runtime, so that Sage can use its Sage backend and SymPy can use the normal backend(s) in the same process. I don't know if this use case is important enough to add this complexity to mpmath, however. You could argue this is sort of a Sage issue. There are a lot of bad things that can happen if you import Sage in a normal Python environment (e.g., IIRC unless this has changed, it also hooks the interpreter in some ways that makes exceptions print differently). Installing Sage into the same Python environment you plan to use for non-Sage things is a bad idea. If gentoo is doing that, it should reconsider. But the fact that mpmath just imports sage when it can find it exacerbates this problem. That means that, prior to this fix, simply doing |
|
I acknowledge that the situation sympy/mpmath/sage has been ongoing for some time. sage in sage-on-gentoo has been a normal python package that you can import from python since about sage-5.0. Recent sympy have not exhibited problems in sage-on-gentoo but for a while I had some environment variable specifically set for it. In effect this is the first time in a couple of years since I had an issue of this kind. But the fact that once sage is installed you have to explicitly tell mpmath not to use it is something I understand you find less than ideal. I am currently trying a simple fix in upstream sage but I don't know if it will catch enough things. |
|
I don't know if this still the case, but Sage used to have pretty stringent pinning of some dependencies, which was another reason to prefer using a separate environment for conda. @isuruf would need to comment on whether that is still the case. Also as I mentioned, I noticed back in 2018 that Sage was hooking the interpreter in some ways when it was imported. I don't know if this is still relevant. I don't follow Sage development at all, though, so it is very possible that these are no longer significant issues. It definitely was the case then that Sage was not at all designed to be installed as a library alongside a normal Python environment. That's obviously an even bigger issue when something like |
|
Still does need some stringent pinning of some dependencies (singular, pari...). This is unfortunate but also the result of the fact that most of those packages have APIs that are not very stable. Separate environment and other containment strategies are obviously a good way to have a handle on those issues from the user perspective, not so much from the regular packager perspective. |
|
For conda environments are trivial, so it isn't a big deal. The main issue really is messaging to users that Sage is very much a package that you want to have in a separate environment, rather than your "main" environment. I understand that no all package managers have straightforward environments like conda does, including most Linux system package managers, so it's a harder problem there. |
|
Nod in agreement. The ticket you opened years ago is getting renewed interest https://trac.sagemath.org/ticket/25445. I think the fact sage is not working properly if you are not using the sage backend is a sage bug. It shouldn't matter, beside possible numerical noise, and the fact it does means the internal of mpmath are abused. |
It's possible to install the Sage system as a normal Python package, as
e.g. in Fedora/Debian. In this case, presence of
sage.allis not anindicator whether the user is running Sage, and checking for 'SAGE_ROOT'
is more reliable.
There are some behavior differences in mpmath with the Sage backend,
(e.g.
mpmath.ker(0, 0)is0on sage butinfon gmpy), but a larger reasonfor this change could be that the Sage backend probably makes sense mostly
when using Sage.