On 27 February 2024 20:21:26 GMT, Nils Bruin <nbr...@sfu.ca> wrote:
>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.
The reason for having a bad integration with upstream Jupyter is simple - we
haven't really tried to do it properly, that's all.
And I am not able to get Sage's Jupyter properly working. Also people here
complain that they can't use Sage's Jupyter offline (it's cause we keep on
using Mathjax2, for the sole reason that long formulas dont wrap around,
instead there is a slider to view them). So if one wants offline MathJax, e.g.
for a presentation, Sage's Jupyter is useless.
With an ability to have standard pip packages, this would be something to look
at - cause without this ability it's always some ad hoc non-official stuff, may
work, or not, no one cares much.
> 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.
If you pin a version, or even if you don't, there should be no difference
between what we install, and what comes from pip install. Gentoo provides a
very modern upstream Sphinx, and it works with Sage, for quite some time.
> 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/978D1F98-CC2C-404A-84DB-110025C7FDB3%40gmail.com.
