Thanks, this is very helpful! I gave it a spin for the 1.13.1 docs - it's live on https://docs.scipy.org/doc/scipy/reference/generated/scipy.cluster.vq.vq.html now:

To enable:

$ ssh your-username@docs.scipy.org
$ cd /srv/docs_scipy_org/doc/scipy-1.13.1
$ vim try_examples.json  # edit the ignore list to remove: ".*"

Putting the pattern back immediately disables things again.

One thing I noticed is that the vertical height is too small. Changing it in try_examples.json from 400px to 600px doesn't seem to change anything. Is it possible that the 1.13.1 docs were built with a jupyterlite-sphinx version that doesn't handle min_height yet?

@agriyakhetarpal you'll be interested in this I'm sure (and may know the answer for the min_height question perhaps?).

One thing I noticed is that the vertical height is too small. Changing it in try_examples.json from 400px to 600px doesn't seem to change anything. Is it possible that the 1.13.1 docs were built with a jupyterlite-sphinx version that doesn't handle min_height yet?

Thanks for tagging me, @rgommers! The last paragraph in the Global Configuration section under the TryExamples directive page explains the reasons why a global minimum height that's set in conf.py does not apply to this directive. For a particular example, it has to be set manually if one has to change it (which I understand is convenient for an auto-generated doctest-based example; we could have a setting that sets a minimum height dynamically based on the amount of code content by tracking the number of lines and cells or something)

https://jupyterlite-sphinx.readthedocs.io/en/latest/directives/try_examples.html#global-min-height suggests we need global_min_height rather than min_height?

we could have a setting that sets a minimum height dynamically based on the amount of code content by tracking the number of lines and cells or something)

That's exactly what we don't want I think. The minimum height should be okay by default, it's much too small now. It works fine in the PyWavelets API reference docs.

Yep, global_min_height works (this is 600px):

Now we just need to pick the right value. 400px actually seems fine to me:

500px could also work; 600px seems a bit much (you can always open in a separate tab)

Ah, yes. Sorry about that. min_height instead of global_min_height is a bug in SciPy's try_examples.json. I can fix it in this PR.

I just added these specific commands @rgommers gave above to releasing.rst.inc

$ ssh your-username@docs.scipy.org
$ cd /srv/docs_scipy_org/doc/scipy-1.13.1
$ vim try_examples.json  # edit the ignore list to remove: ".*"

Thanks Melissa!

• How is the kernel created and connected to our docs?

I'm not aware of the underlying details but I know:

We have the jupyterlite-pyodide-kernel in our docs requirements here:

which get installed here

There's some metadata in the generated notebooks that tells the system to look for a Python kernel.

    nb["metadata"] = {
        "kernelspec": {
            "display_name": "Python",
            "language": "python",
            "name": "python",
        },
        "language_info": {
            "name": "python",
        },
    }

• Where are the ipynb files generated by the docs build?

The path to these notebooks is scipy/doc/build/html/lite/files

• What is the path for a generated ipynb for a particular example/page?

This might need some work for the sake of ergonomics. Each notebook's name is based on a uuid4 and these will be different each time the docs are generated. One can look in the generated html file for a piece of documentation, like
scipy/doc/build/html/reference/generated/scipy.integrate.quad.html

and find the try_examples_button

<button class="try_examples_button"
 onclick="window.tryExamplesShowIframe('732d240c-3ec6-4d9f-8c2b-8318deab1a79','284465d0-7adb-432b-995a-c1e126ab17b9','795d8fdc-a0ba-4c79-97ab-90de384b72b5','../../lite/tree/../notebooks/?path=7b2233aa_1a1d_40fe_9a23_4846c195450f.ipynb','None')">
Try it in your browser!
</button>

The name of the .ipynb file will be present there, and then you can find the file in the path above. I went with uuids to avoid clashes, but maybe that's not the most convenient thing.

So, does that mean we are using a vanilla kernel? I thought there was a step to build and select a specific kernel with a specific scipy version? Is that outdated info?

So, does that mean we are using a vanilla kernel? I thought there was a step to build and select a specific kernel with a specific scipy version? Is that outdated info?

Having a specific SciPy version is in the works, but isn’t ready yet. In the jupyterlite-sphinx docs I was just trying to point out that the problem exists. It’s much easier to solve for other projects though. SciPy is tough because of all of the Fortran.

Nice to see this has been merged and all examples are enabled by default!

Not crucial but I was a bit confused originally because I was looking at the dev website and interactive examples are not enabled on the dev website for example https://scipy.github.io/devdocs/reference/generated/scipy.cluster.vq.vq.html#c58617e0-b72b-447b-b0cf-19e78ade50b3. I guess the reason is that you want it disabled by default and then enabled explicitly by sshing to the doc server and editing try_examples.json?

I guess the reason is that you want it disabled by default and then enabled explicitly by sshing to the doc server and editing try_examples.json?

Long term, no. But I think for now it's more confusing then helpful to default to adding the buttons, since any local changes to scipy won't be accessible from that button until we solve the problems related to nightly or local wheels for Pyodide.

Ah yeah good point indeed, I didn't think of this.

By the way there is likely a way to extend https://github.com/lesteve/scipy-tests-pyodide to run the Scipy doctests inside Pyodide and get an idea of what works and what doesn't, I need to look at it.

Minor side-comment: what you call examples (code examples in .py docstrings) are different than what scikit-learn call examples (gallery examples i.e. https://scikit-learn.org/stable/auto_examples) 😉

Re examples: yes indeed. We have longer-form content too in the User Guide, and that is still in the process (actually near the beginning of the process) to be migrated to executable content: https://scipy.github.io/devdocs/tutorial/index.html#executable-tutorials. Long-form .rst files (like this one for fft currently don't have buttons to run with JupyterLite.

By the way there is likely a way to extend https://github.com/lesteve/scipy-tests-pyodide to run the Scipy doctests inside Pyodide and get an idea of what works and what doesn't, I need to look at it.

That looks like quite magical hackery to make things work. Would the need for this be removed though by simply building a separately installable scipy-tests wheel? We just made that very easy and documented it at http://scipy.github.io/devdocs/building/redistributable_binaries.html#stripping-the-test-suite-from-a-wheel-or-installed-package.

That looks like quite magical hackery to make things work

Not sure which part you are talking about, but it certainly is a bit 😅.

A few things to note:

• the main motivation was to test Pyodide main branch regularly to make sure that there were no regression in Scipy without noticing. The tests inside the Pyodide project are only testing Scipy functionality in a shallow manner.
• Pyodide + packages are built in debug mode to try to have more informative Pyodide stack-traces
• because running Scipy code can crash the Python interpreter (deterministic Pyodide fatal errors or random memory corruptions) the tests are run by submodule so that a fatal error in one of the submodules does not affect the rest of the test