Proposal: Demote jupyter-jsmol and tachyon to optional

[Matthias Koeppe]

jupyter-jsmol is the current standard package providing javascript version of Jmol (which I proposed to demote to optional in https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg, https://github.com/sagemath/sage/pull/38504). I propose to demote it to "optional". (In https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg/m/OwGjF4GiBQAJ (2020), Antonio Rojas already asked if there is any reason for not making jsmol optional too because three.js is our default 3d renderer.)

tachyon is a standard package providing a raytracer, dating back to 1994. It has a precarious maintenance status. Fedora has orphaned this package, and it is not available in the current release 40 (https://src.fedoraproject.org/rpms/tachyon), Debian has an extensive set of patches that have not been upstreamed (https://sources.debian.org/patches/tachyon/0.99~b6+dsx-12/). The Arch Linux package (https://archlinux.org/packages/extra/x86_64/tachyon/) is maintained by Antonio Rojas; sage is listed as the only package depending on it. I propose to demote this package to optional as well.

Jmol (not jupyter-jsmol) and Tachyon serve the purpose of saving 3d graphics as png files, in particular for our PDF documentation. 

I propose to replace this function (exclusively provided by these two packages in Sage) by using the tool Playwright, which installs a browser such as Chromium and screenshots an arbitrary webpage as a PNG file. By using it on a three.js rendering of 3d graphics, we can thus save the 3d graphics as a PNG file. This is PR https://github.com/sagemath/sage/pull/38509 (needs review). This is much heavier-weight technology than tachyon, but it has excellent mainstream maintenance status.

[François Bissey]

Making all those packages optional sounds good. I am not completely sure
about playwright. It feels a bit heavy to shoehorn to produce
documentation from source. I need a bit more time to think about it.

Using binary produced documentation packages for "stable" releases is a
fine option, but producing documentation in develop or on top of branch
may become onerous.

Definitely need to dig a bit more in the npm scene for that stuff.

François

On 20/08/24 12:07, Matthias Koeppe wrote:
> jupyter-jsmol
> <https://doc.sagemath.org/html/en/reference/spkg/jupyter_jsmol.html#spkg-jupyter-jsmol> is the current standard package providing javascript version of Jmol (which I proposed to demote to optional in https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg, https://github.com/sagemath/sage/pull/38504). I propose to demote it to "optional". (In https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg/m/OwGjF4GiBQAJ (2020), Antonio Rojas already asked if there is any reason for not making jsmol optional too because three.js <https://doc.sagemath.org/html/en/reference/spkg/threejs.html#spkg-threejs> is our default 3d renderer.)
>
> tachyon
> <https://doc.sagemath.org/html/en/reference/spkg/tachyon.html#spkg-tachyon> is a standard package providing a raytracer, dating back to 1994. It has a precarious maintenance status. Fedora has orphaned this package, and it is not available in the current release 40 (https://src.fedoraproject.org/rpms/tachyon), Debian has an extensive set of patches that have not been upstreamed (https://sources.debian.org/patches/tachyon/0.99~b6+dsx-12/). The Arch Linux package (https://archlinux.org/packages/extra/x86_64/tachyon/) is maintained by Antonio Rojas; sage is listed as the only package depending on it. I propose to demote this package to optional as well.

>
> Jmol (not jupyter-jsmol) and Tachyon serve the purpose of saving 3d
> graphics as png files, in particular for our PDF documentation.
> I propose to replace this function (exclusively provided by these two
> packages in Sage) by using the tool Playwright, which installs a browser
> such as Chromium and screenshots an arbitrary webpage as a PNG file. By
> using it on a three.js rendering of 3d graphics, we can thus save the 3d
> graphics as a PNG file. This is PR
> https://github.com/sagemath/sage/pull/38509 (needs review). This is much
> heavier-weight technology than tachyon, but it has excellent mainstream
> maintenance status.
>

> --
> 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+...@googlegroups.com
> <mailto:sage-devel+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/337d1392-f7bf-4dc1-8c9a-a40cfcd59eefn%40googlegroups.com <https://groups.google.com/d/msgid/sage-devel/337d1392-f7bf-4dc1-8c9a-a40cfcd59eefn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nils Bruin]

It's unfortunate that tachyon isn't maintained properly. It's a nice piece of software. It looks like it has been adopted by VMD (software developed by the biophysics group at Illinois -- it looks like the software is opensource and available without cost, but is under a restrictive licence, so can never be widely supported/distributed by distributions), so based on that it doesn't look good for tachyon becoming properly supported.

I can see how "Playwright" is an  attractive option since it co-opts the renderer that is already available in modern browsers. It is definitely a nice option to have because it should produce pictures that exactly match what people are producing in the browser. While currently it is probably well-supported, I could see how longer term this is going to be a rather fragile solution, because we'd be dependent on an interface to communicate with a browser. I assume the proposal wouldn't mean that we'd ship a browser with sagemath?

I almost never use 3D plotting machinery myself (the last time I tried to use threejs it was for a demo and it was flaky in the browser -- it ended up not working when I needed it, but it did work afterwards), but it would seem to me one would mainly want an export method to write a scene so that well-established rendering software like blender (which I think can run from the commandline) can process it. It would then not be sagemath's role to provide the rendering software, much in the same way that we don't package a pdf viewer either -- we could provide functionality to produce images assuming "blender" is available on the path, though. That would replace one role that tachyon could be used for (although I'm not sure how many people have used sagemath+tachyon to produce publication-quality pictures.

[Matthias Koeppe]

On Monday, August 19, 2024 at 5:52:17 PM UTC-7 Nils Bruin wrote:

I assume the proposal wouldn't mean that we'd ship a browser with sagemath?

After installing playwright, one runs "playwright install" to install the browser(s). This requires internet connectivity. 

In the branch of https://github.com/sagemath/sage/pull/38509, I do this in the script package "playwright_chromium".

Because the installation requires internet connectivity, it is not suitable as a standard package according to our policy. My branch makes the new packages optional.

[Matthias Koeppe]

On Monday, August 19, 2024 at 5:52:17 PM UTC-7 Nils Bruin wrote:

I can see how "Playwright" is an  attractive option [...] While currently it is probably well-supported, I could see how longer term this is going to be a rather fragile solution, because we'd be dependent on an interface to communicate with a browser.

I don't share this concern. Automatic screenshotting is an extremely high-profile technology that is unlikely to disappear any time soon, with numerous implementations available.

[Kwankyu Lee]

As far as I remember from the discussion in https://github.com/sagemath/sage/issues/33513, saving 3d graphics to png files is already possible from the menu "Save as PNG". For inclusion of 3d graphics as png files to our pdf documentation, one may do it manually by including the png files into the documentation.

If taking screenshots from 3d graphics automatically for pdf documentation is the only reason to consider playwright,  I think the maintenance burden of the new package is heavier than the benefits.

[Eric Gourgoulhon]

Le mardi 20 août 2024 à 08:46:32 UTC+2, Kwankyu Lee a écrit :

As far as I remember from the discussion in https://github.com/sagemath/sage/issues/33513, saving 3d graphics to png files is already possible from the menu "Save as PNG".

Indeed, this works well from the threejs menu, but this has to be done manually.

 

For inclusion of 3d graphics as png files to our pdf documentation, one may do it manually by including the png files into the documentation.

There are tons of png files in the "3d Graphics" section of the documentation:  

https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html

It would be quite a burden to maintain this manually. 

If taking screenshots from 3d graphics automatically for pdf documentation is the only reason to consider playwright, 

Note that this regards not only the pdf documentation (hardly used I guess...) but also the online html documentation, as posted at

https://doc.sagemath.org/html/en/reference/plot3d/

Currently, Jmol is used to automatically generate the numerous png files involved in this documentation. The drawback of Jmol-generated png files is that they do not exactly correspond to what the user gets on his/her screen in a Jupyter notebook with the default viewer (threejs). So having an automated way to generate png from threejs would be very nice!

Eric. 

[Kwankyu Lee]

On Tuesday, August 20, 2024 at 7:07:54 PM UTC+9 Eric Gourgoulhon wrote:

There are tons of png files in the "3d Graphics" section of the documentation:  

https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html

It would be quite a burden to maintain this manually. 

Meanwhile I looked into the responsible code and studied how Jmol/Tachyon is used in rendering images from 3d graphics via sphinx_plot() via ".. PLOT::"

As generating these images is already automated, I would not advocate for switching to a manual way. Moreover, I now see that the automated way helps in keeping the documentation source small (while compiling the documentation takes longer).

I just want to note that maintaining png files is no burden once added (either manually or in bulk using playwright) as the documentation rarely changes.

 

The drawback of Jmol-generated png files is that they do not exactly correspond to what the user gets on his/her screen in a Jupyter notebook with the default viewer (threejs).

I agree. Manually-generated images have the same benefit :-)

[Michael Orlitzky]

Playwright (via Chromium) would add another non-portable component to
sage, which incidentally downloads several hundred megabytes of
untrusted executable code from god-knows-where.

As a distro package, tachyon is mildly annoying, but all that it really
needs is a sane build system. The existing one is a case study in what
happens when you try to recreate autotools in undocumented Makefile
fragments. Ultimately it's not a complicated program to build.

The author doesn't have a bug tracking / PR system in place or an
obvious way to accept contributions. Has anyone tried contacting him?
If we spent a day collectively writing configure.ac and Makefile.am, it
seems to me that we could solve all of the problems shared by Sage,
Debian, Arch, Gentoo, etc.

[Ricardo Buring]

As an alternative to (automatically) opening a web browser, perhaps one could automate (three.js) exporting to glTF and a small renderer (raylib?) generating the image.

Best,

Ricardo

[Matthias Koeppe]

On Tuesday, August 20, 2024 at 6:54:00 AM UTC-7 Michael Orlitzky wrote:

As a distro package, tachyon is mildly annoying, but all that it really
needs is a sane build system. The existing one is a case study in what
happens when you try to recreate autotools in undocumented Makefile
fragments. Ultimately it's not a complicated program to build.

[...] If we spent a day collectively writing configure.ac and Makefile.am, it

seems to me that we could solve all of the problems shared by Sage,
Debian, Arch, Gentoo, etc.

That's certainly all true. In fact, the Debian patches (https://sources.debian.org/patches/tachyon/0.99~b6+dsx-12/) already carry out this autotoolization of the package (though I haven't looked at the details at all).

But even if done, it remains that tachyon is a package that as of 2024 it does not appear to be used by anyone else (at least in the Python "ecosystem").

[Matthias Koeppe]

On Tuesday, August 20, 2024 at 7:04:36 AM UTC-7 Ricardo Buring wrote:

As an alternative to (automatically) opening a web browser,

Just to clarify, the web browser is not "opened" in the sense of popping up on the screen. It's done by playwright in a headless operation.

 

perhaps one could automate (three.js) exporting to glTF and a small renderer (raylib?) generating the image.

Could you elaborate on this idea please?

[Matthias Koeppe]

On Monday, August 19, 2024 at 11:46:32 PM UTC-7 Kwankyu Lee wrote:

If taking screenshots from 3d graphics automatically for pdf documentation is the only reason to consider playwright [...]

I'll note that playwright can also used by Jupyter to export notebooks in PDF format. (For details, see ticket description of https://github.com/sagemath/sage/pull/38509)

[Nils Bruin]

On Tuesday 20 August 2024 at 06:54:00 UTC-7 Michael Orlitzky wrote:

[...]

As a distro package, tachyon is mildly annoying, but all that it really
needs is a sane build system. The existing one is a case study in what
happens when you try to recreate autotools in undocumented Makefile
fragments. Ultimately it's not a complicated program to build.

The author doesn't have a bug tracking / PR system in place or an
obvious way to accept contributions. Has anyone tried contacting him?
If we spent a day collectively writing configure.ac and Makefile.am, it
seems to me that we could solve all of the problems shared by Sage,
Debian, Arch, Gentoo, etc.

Regardless of Tachyon's status in sagemath, such an action would be of great benefit to the open source community at large. The author of Tachyon, John Stone, is now part of the group that develops VMD, so I imagine packaging tachyon in a standalone fashion is not necessarily a priority for him. Even with the build process updated, the package would require someone committing to maintain it (which hopefully would be a minor task). Ideally this would happen in collaboration with the original author, but the code is licensed BSD-3, so I don't think it's technically necessary.

 

[Kwankyu Lee]

On Wednesday, August 21, 2024 at 2:57:31 AM UTC+9 Matthias Koeppe wrote:

I'll note that playwright can also used by Jupyter to export notebooks in PDF format. (For details, see ticket description of https://github.com/sagemath/sage/pull/38509)

That elevates playwright to be a somewhat natural member of our fleet of packages group "Front-end, graphics, document preparation": https://doc-release--sagemath.netlify.app/html/en/reference/spkg/#front-end-graphics-document-preparation.

Installing playwright via pip was a breeze. It does not feel heavy.

[John H Palmieri]

On Tuesday, August 20, 2024 at 6:45:41 AM UTC-7 Kwankyu Lee wrote:

On Tuesday, August 20, 2024 at 7:07:54 PM UTC+9 Eric Gourgoulhon wrote:

There are tons of png files in the "3d Graphics" section of the documentation:  

https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html

It would be quite a burden to maintain this manually. 

Meanwhile I looked into the responsible code and studied how Jmol/Tachyon is used in rendering images from 3d graphics via sphinx_plot() via ".. PLOT::"

As generating these images is already automated, I would not advocate for switching to a manual way. Moreover, I now see that the automated way helps in keeping the documentation source small (while compiling the documentation takes longer).

I just want to note that maintaining png files is no burden once added (either manually or in bulk using playwright) as the documentation rarely changes.

I just built Sage on an OS X machine with a bunch of homebrew packages installed. It took under 20 minutes to build everything except the documentation, while the file sagemath_doc_html-none.time says

real 24m20.264s
user 34m51.512s
sys 9m1.973s

Oh, and this is with "SAGE_DOCBUILD_OPTS=' --no-plot'". If the documentation is taking longer than everything else combined, maybe we should consider distributing all of the documentation pre-built as a tarball, not just some png files. (I have resisted this in the past, but I am changing my mind.) Packages that are necessary to build the documentation could be "optional," or there could be a new type for them. The standard "make" would use the pre-built tarball, while another "make" target could build the documentation from scratch. This could make the build process faster with fewer associated standard packages.

[Kwankyu Lee]

On Wednesday, August 21, 2024 at 9:42:42 AM UTC+9 John H Palmieri wrote:

... maybe we should consider distributing all of the documentation pre-built as a tarball, not just some png files. (I have resisted this in the past, but I am changing my mind.) Packages that are necessary to build the documentation could be "optional," or there could be a new type for them. The standard "make" would use the pre-built tarball, while another "make" target could build the documentation from scratch. This could make the build process faster with fewer associated standard packages.

Good idea. Though we have the dichotomy that installing sage from source is for developers and installing prebuilt sage is for non-developer users, it is not a bad idea for a non-developer user to install sage from source. For such users, installing pre-built doc, which is platform-independent, would save much time.

Alternatively, the standard "make" would first attempt to download the pre-built tarball (from github release assets), and rebuild the doc only if downloading fails or sagelib is modified (which would entail installing all "optional" packages necessary for doc build).

[François Bissey]

I used to provide pre-built doc for sage-on-gentoo. I stopped when I
started to move to modular sage packages (sage_conf, sage_setup,...).
I think it totally make sense.

However developers and people that work on the documentation are still
left with having to use the unpalatable stuff. Is playwright any better
than jmol? Well it is easier to install and possibly better maintained
but it is still a big blob of binary goo. In fact, I suspect it will
turn out to be a bigger blob. My jmol install is clocking at 91.7MB and
my chrome install is 298MB.
Now having the plot looking exactly like what you will typically produce
instead of being similar is a big plus.

François

[Matthias Koeppe]

On Tuesday, August 20, 2024 at 5:42:42 PM UTC-7 John H Palmieri wrote:

I just built Sage on an OS X machine with a bunch of homebrew packages installed. It took under 20 minutes to build everything except the documentation, while the file sagemath_doc_html-none.time says real 24m20.264s [...] with "SAGE_DOCBUILD_OPTS=' --no-plot'". If the documentation is taking longer than everything else combined, maybe we should consider distributing all of the documentation pre-built as a tarball [...]

This should be possible with https://github.com/sagemath/sage/pull/36730

 

Packages that are necessary to build the documentation could be "optional," or there could be a new type for them.

Effectively we already have that -- "configure --disable-doc" disables the standard packages that are only needed by the docbuild.

 

The standard "make" would use the pre-built tarball, while another "make" target could build the documentation from scratch. This could make the build process faster with fewer associated standard packages.

Good idea. Bonus points for making incremental builds starting from the prepackaged documentation fast. (This is the tricky bit.)

[Marc Culler]

On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:

 it is not a bad idea for a non-developer user to install sage from source.

I disagree.  It is a bad idea, for so many reasons:

* It requires a lot of time and work which is completely unrelated to using Sage.

* It will almost certainly fail.

* Even if it does succeed, it provides no benefit to a user who only wants to use Sage.  But it does have lots of negative side effects, including creating a 10GB subdirectory of the user's home which becomes totally  useless if it is moved, and forcing the installation of many packages and, possibly, package managers, which are useless to someone who is not interested in writing code.

Even the suggestion that this is a reasonable thing for a "non-developer user" to do adds a huge obstacle to using Sage.

On the other hand, I think that distributing pre-built documentation is a good idea.

- Marc

[Nils Bruin]

On Wednesday 21 August 2024 at 08:03:03 UTC-7 marc....@gmail.com wrote:

On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:

 it is not a bad idea for a non-developer user to install sage from source.

I disagree.  It is a bad idea, for so many reasons:

* It requires a lot of time and work which is completely unrelated to using Sage.

* It will almost certainly fail.

* Even if it does succeed, it provides no benefit to a user who only wants to use Sage.  But it does have lots of negative side effects, including creating a 10GB subdirectory of the user's home which becomes totally  useless if it is moved, and forcing the installation of many packages and, possibly, package managers, which are useless to someone who is not interested in writing code.

Using sage may include using cython. Sage and Jupyter have excellent support for writing little snippets of cython code and have them integrate with python instructions around them with virtually no overhead, via "%%cython". I have definitely talked to people who use sage who (wanted to) use cython for mathematical inner loops that have to be fast and have no inclination to contribute code changes to sagemath. Those are (sophisticated) users.

At least building sagelib is a great way of certifying that cython works correctly. I agree that compiling the other parts of sage has very little practical benefit even for a developer. Because full functionality of sage implies a working compiler tool chain, compiling sage from source even for users is a much more reasonable proposition than for most other software.

[Marc Culler]

Using cython within Sage via the %%cython magic command definitely does not require building Sage from source.  That magic command works fine in the Sage_macOS binary distribution of SageMath.  The cython pip package is included in that binary distribution, because it gets built and installed as part of the Sage build.  Yes, you do need to have a C toolchain installed on your mac.  But that requires nothing more than opening the Terminal app and typing "xcode-select --install".  That works on a pristine macOS system with no third party packages installed.

I realize that it is a paradigm shift from years of Sage practice, but overcoming the expectation that all of our users are, or secretly want to be, developers and/or system administrators makes Sage much more accessible to users, and that means having many more users.

- Marc 

[Marc Culler]

I should add that, in truth, "xcode-select --install" is all that is really required in order to build Sage.  But you would not get that impression from reading about how to  build Sage.  (I consider that to be a great strength of Sage's current structure, and I am also aware that many people strongly disagree with me about that.)  I think that a user who only does that, without installing anything else, will be much more likely to succeed at building Sage, even though it will take longer.  But that is beside the point,  the point being that for many, probably most, users of Sage, building from source is a bad idea.

- Marc

[Dima Pasechnik]

On 21 August 2024 16:03:02 BST, Marc Culler <marc....@gmail.com> wrote:
>
>On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:
>
> it is not a bad idea for a non-developer user to install sage from source.
>
>

>I disagree. It *is* a bad idea, for so many reasons:

it's only if you are on a bad platform to begin with.
On Gentoo Linux, just do

emerge sagemath-standard

and it will be built from source (as is normal for Gentoo packages) :-)

On other platforms with most of the dependencies available, it should not be much harder than building scipy from source. It currently is tricky, but this is entirely our fault.

Dima

[Dima Pasechnik]

On Wednesday, August 21, 2024 at 6:03:29 PM UTC+1 Marc Culler wrote:

Using cython within Sage via the %%cython magic command definitely does not require building Sage from source.  That magic command works fine in the Sage_macOS binary distribution of SageMath.  The cython pip package is included in that binary distribution, because it gets built and installed as part of the Sage build.  Yes, you do need to have a C toolchain installed on your mac.  But that requires nothing more than opening the Terminal app and typing "xcode-select --install".  That works on a pristine macOS system with no third party packages installed.

 what if you have a version mismatch between the toolchain used to build the shipped binary,
and XCode you installed locally? I'd expect trouble, in particular with C++.

[Marc Culler]

On Wed, Aug 21, 2024 at 12:35 PM Dima Pasechnik <dim...@gmail.com> wrote:

 what if you have a version mismatch between the toolchain used to build the shipped binary,
and XCode you installed locally? I'd expect trouble, in particular with C++.

When I tested the %%cython magic command I was running a beta version of macOS 15 with XCode 16.1 beta, while the SageMath app was built on macOS 14 with XCode 16.0.  The python function that I used was trivial - it just multiplied the argument by 2.0 and returned the product.  But it worked fine.  I don't know if it is possible to force C++ to be used with the %%cython magic command.

 The C and C++ runtimes are distributed with the operating system, and so far we have not seen problems arising from users having a different operating system version from the one used to build the app.

it's only if you are on a bad platform to begin with.

It is not really about which platform(s) I am on, it is about which platform a Sage user is on.  I don't think that telling users that they chose to install a bad operating system is likely to encourage people to use Sage.

[dmo...@deductivepress.ca]

It appears to me that we are seeing a culture clash here.  I think what Marc says is correct in regard to mac users, but, for all I know, it may be less (or not at all) true about linux users.

In particular, I am pretty sure that the vast majority of mac users have never built a program from source, and do not know what "homebrew" or "package manager" means.  A mac user expects to download either a ready-to-use application or a ".pkg" installer file that just needs to be double-clicked.  Many, probably most, are fearful of doing anything at the command line (and don't understand it).  As Marc said, expecting the typical mac user to build sage from source is adding a huge obstacle.

[G. M.-S.]

I think the clash is much more basic than that.

It is developers versus users.  Users who hoped to do (some) mathematics with a computer.

So far, it seems to me most discussions are developer-centric, Marc being among the exceptions giving another POV.

Guillermo

[Nils Bruin]

On Wednesday 21 August 2024 at 12:36:02 UTC-7 GMS wrote:

I think the clash is much more basic than that.

It is developers versus users.  Users who hoped to do (some) mathematics with a computer.

So far, it seems to me most discussions are developer-centric, Marc being among the exceptions giving another POV.

well, the list is called "sage-devel". I definitely appreciate Marc's perspective and it is a useful one to add to the mix, because there are definitely different compromises in the linux and OSX ecosystems.

I'm pretty sure that previously people did have problems with running cython successfully on installed-from-binary sage on linux platforms. Note that having a functional cython is not just important for having "%%cython" work. It's also relevant for third party extensions such as https://github.com/nbruin/RiemannTheta. So I think that presently installing sage from binary *without* a C toolchain is producing a hobbled install. It may be a reasonable compromise for people who don't need it, but the design of sagemath (and one of its strengths!) does require the ability to seamlessly move from python to cython. And this is not just a user/developer divide.

[Matthias Koeppe]

In the interest of keeping the discussion focused, I would ask that commenters use a separate thread if they wish to comment on the matters of "building the Sage distribution from source vs. using a prebuilt binary distribution" and other unrelated matters. Thanks.

[G. M.-S.]

I am sorry.

Once I tried to start a discussion on this developers vs. users topic.  Nobody answered.  My fault surely.

I shall stop here.

Guillermo

[Matthias Koeppe]

On Tuesday, August 20, 2024 at 6:44:50 PM UTC-7 Matthias Koeppe wrote:

On Tuesday, August 20, 2024 at 5:42:42 PM UTC-7 John H Palmieri wrote:

I just built Sage on an OS X machine with a bunch of homebrew packages installed. It took under 20 minutes to build everything except the documentation, while the file sagemath_doc_html-none.time says real 24m20.264s [...] with "SAGE_DOCBUILD_OPTS=' --no-plot'". If the documentation is taking longer than everything else combined, maybe we should consider distributing all of the documentation pre-built as a tarball [...]

This should be possible with https://github.com/sagemath/sage/pull/36730

Help would be very welcome on the following improvement for the docbuild:

Currently many copies of _static are in the HTML wheels (because wheels cannot store symlinks). We should deduplicate the _static directories by rewriting the links instead of using symlinks. This would also fix a problem on WSL. See WSL: Chrome on Windows does not find the _static style in built HTML doc  #35538 (comment).

[Matthias Koeppe]

The following PRs are open for review:

- build/pkgs/jupyter_jsmol: Change to optional

- Demote jmol to optional

On Monday, August 19, 2024 at 5:13:29 PM UTC-7 Matthias Koeppe wrote:

jupyter-jsmol is the current standard package providing javascript version of Jmol (which I proposed to demote to optional in https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg, https://github.com/sagemath/sage/pull/38504). I propose to demote it to "optional". (In https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg/m/OwGjF4GiBQAJ (2020), Antonio Rojas already asked if there is any reason for not making jsmol optional too because three.js is our default 3d renderer.)

tachyon is a standard package providing a raytracer, dating back to 1994. It has a precarious maintenance status. Fedora has orphaned this package, and it is not available in the current release 40 (https://src.fedoraproject.org/rpms/tachyon), Debian has an extensive set of patches that have not been upstreamed (https://sources.debian.org/patches/tachyon/0.99~b6+dsx-12/). The Arch Linux package (https://archlinux.org/packages/extra/x86_64/tachyon/) is maintained by Antonio Rojas; sage is listed as the only package depending on it. I propose to demote this package to optional as well.

Jmol (not jupyter-jsmol) and Tachyon serve the purpose of saving 3d graphics as png files, in particular for our PDF documentation. 

I propose to replace this function (exclusively provided by these two packages in Sage) by using the tool Playwright, which installs a browser such as Chromium and screenshots an arbitrary webpage as a PNG file. By using it on a three.js rendering of 3d graphics, we can thus save the 3d graphics as a PNG file. This is PR https://github.com/sagemath/sage/pull/38509 (needs review). This is much heavier-weight technology than tachyon, but it has excellent mainstream maintenance status.