On Tuesday 27 February 2024 at 10:50:55 UTC-8 John H Palmieri wrote:
As Nathan points out, this will likely lead to instability. Someone will upgrade some component, and most of the time that will be fine, but occasionally it will break something on some platform, and it could be annoying to track down the cause. If this leads to Sage failing to build, that's not great, but it would be *far worse* if Sage built and ran but produced some mathematically incorrect answers. Being able to control all of the versions means that our doctests are pretty robust. If we really want to go down the road of unpinning version requirements, I propose that we *always* pin version requirements for the mathematical components of Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the mathematics, but if linbox or pari don't work right (or ore_algebra, if you want a pip package), people could be getting different answers on different platforms and we might not know about it for a while. To maintain the mathematical integrity of the project, we should keep very careful control of the mathematical components of Sage. +1 to this. There is another difference: The jupyter notebook server - notebook kernel interface is not a binary one: it's a protocol. As such, it's hopefully narrower in its definition and a bit more stable. So offering that sagemath offers a notebook kernel that a separately distributed notebook server can connect to is a different dependency structure than depending on libraries being provided. There are some super stable libraries for which external dependencies are OK, but generally (especially components under active development) they are a lot more sensitive. For full functionality we depend on more than vanilla jupyter notebook, though: at some point, jupyter notebook server shipped with a pared-down mathjax and I have not been able to to get proper mathjax working in my system-provided jupyter notebook. We have other components, such as documentation and various plug-ins that we need in jupyter notebook too. This has made the shipped-with-sage jupyter notebook server more reliable to me, even if I'd prefer the system notebook server if that would be reliable to get working. Sphinx is another part of such tooling: it should be able to just read and process markup. We tend to not ship a latex installation with our preprints. However, I don't have experience with how stable sphinx on its own is to judge how much trouble one would get from relying on an external sphinx. Personally, I don't bother building the sage documentation and rely on what is available online instead, so that one wouldn't affect me. -- 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/88accdbb-7d2a-4860-8791-787bf52a8a89n%40googlegroups.com.
