r-wasm / quarto-live

WebAssembly powered code blocks and exercises for both the R and Python languages in Quarto documents
https://r-wasm.github.io/quarto-live/
MIT License
121 stars 7 forks source link

Pyodide seems to interfere with output of r plotly plots #47

Open michaelplynch opened 2 months ago

michaelplynch commented 2 months ago

Problem

Inclusion of pyodide code chunks appears to interfere with plotly output in quarto doc. Not sure if this should be posted here or on the Quarto page.

Expected behaviour

Plotly plots output as normal

Actual behaviour

Plotly plots not output in rendered doc when pyodide code chunk is included as below. Plotly plots also not output in rendered doc when pyodide code chunk is included and eval=FALSE. Plotly plots output as expected when pyodide code chunk removed entirely.

---
title: "test slides"
format:
    live-revealjs
author: "Michael Lynch"
from: markdown+emoji
engine: knitr
editor: source
---

{{< include ./_extensions/r-wasm/live/_knitr.qmd >}}

## Python interactive

````{pyodide eval=TRUE}
num = 8 
num_sqrt = num ** 0.5
num_sqrt

How about some interactive plots?

library(leaflet)
leaflet() %>%
  addTiles() %>%  # Add default OpenStreetMap map tiles
  addMarkers(lng=174.768, lat=-36.852, popup="The birthplace of R")
joelostblom commented 2 months ago

Possibly duplicate of https://github.com/r-wasm/quarto-live/issues/44 if the underlying mechanism that prevents altair and plotly plots from showing is the same. Do plotly plots in python with pyodide out fine?

georgestagg commented 2 months ago

It looks like this has something to do with including the require.js library when loading Pyodide. When I disable loading that library, things begin to work:

Screenshot 2024-08-27 at 17 32 55

I will continue to investigate and report back when I know more.

georgestagg commented 2 months ago

As of commit cbacfc4 this should work better. I've replaced using the requirejs library with loading the Jupyter html-manager directly with a HTML script element.

This works OK for now, but will need to be revisted when we start to implment more of the jupyter widget functionality, since several widgets assume requirejs is available for use.

coatless commented 2 months ago

@georgestagg I think this is probably related to some of AMD loading hiccups that was plaguing monaco;

https://github.com/pyodide/pyodide/issues/4863

Can you boost the default version of Pyodide up to 0.26.2?

https://github.com/pyodide/pyodide/blob/1a665d199ca892811840824d1e50f1599fe8a9f1/docs/project/changelog.md?plain=1#L127

georgestagg commented 2 months ago

The issue we're seeing is not due to Pyodide per se, it just seems that way because we were only including the requirejs library when {pyodide} blocks were in the page.

If I remove the gate, so that requirejs is always loaded into the page, even standard non-WebAssembly R HTML widget features are broken. Here Pyodide isn't even loaded into the page at all, but requirejs is.

Screenshot 2024-08-29 at 17 14 09

So, the problems are wider than something in Pyodide. I think I remember reading some time ago that requirejs just simply does not work well with Quarto -- but I can't find that thread now so it might be old or mis-remembered news.

coatless commented 2 months ago

Well it's true that Quarto is very heavy on JS & CSS dependencies. Though, I'm surprised that Quarto completely obliterates it.

Probably time to briefly look through the partial template to see the built-in dependencies.

joelostblom commented 2 months ago

Here is one quarto issue that mentions problems with require.js in the context of using a jupyter kernel, which I noticed goes away when using a knitr kernel https://github.com/quarto-dev/quarto-cli/issues/3424. Not sure if it is related but thought I would mention it just in case

georgestagg commented 2 months ago

Thanks, I believe that was the thread I was thinking of.

My knowledge was misremembered, though. Carlos’s comment suggests that it’s OJS that requirejs won’t work well with, not Quarto itself, since it replaces the require global.

For now, and probably for the near-to-mid future, I think we can just get away with not including requirejs. I don’t think we’ll need it until we’re wanting to support advanced custom Jupyter Widgets, and we don’t even have the standard widgets communicating back with the Python session yet.