What are the dependencies that you worry about specifically? Is this something that maybe can be fixed in nbconvert, by having optional dependencies?

What I like about the suggested approach is that nbconvert solves a problem that we need, and I would rather improve the whole jupyter ecosystem (that is nbconvert) than trying to solve the same issue in multiple packages.

I feel your pain, and I'm not saying nbconvert is the only way to go, but if we can make the pain go away it will be a win for all. Do you see a way that would make everybody happy? Maybe a concrete series of steps that need to be taken before you are willing to take nbconvert as a dependency?

These are the packages that nbconvert needed to install for me (in a fresh conda environment with only pip installed, just as an FYI.

mistune, six, webencodings, bleach, MarkupSafe, jinja2, testpath, pandocfilters, entrypoints, pygments, defusedxml, ipython-genutils, decorator, traitlets, jupyter-core, jsonschema, nbformat, nbconvert

No idea which of these is more/less beefy than others, just an FYI :-)

One path forward is to nest any nbconvert imports in functions that need it. Then projects that don't need to use it (i.e., all existing projects) don't need to change their deps, but new projects that want it can sort it out.

It does increase our overhead a bit. However, I have a keen interest in getting this to work for MNE, so I can volunteer to take care of the sphinx-gallery CIs.

@GaelVaroquaux does that sound like a viable path forward?

@maartenbreddels still interested in working toward this?

I am working on this but trying a different, less opinionated approach.
The idea is:

• Several thumnail_target_* directives that are free to do what they want (e.g. run some code in the python process, run a piece of c++ code in a Jupyter kernel) but should put a thumbnail and metadata in env.thumbnails.
• Have a thumbnail directive that creates a thumbnail with the exact same style as sphinx-gallery (I have a local package setup that just uses sphinx-gallery as a dependency) and link to the targets (identified by an id/ref).

This seems to me as the path of least resistance. I'm still in doubt if I should do a PR to this repo, or if is should be a new package. I'm trying to reuse as much as possible from sphinx_gallery.

I'm still in doubt if I should do a PR to this repo, or if is should be a new package.

This new proposal looks like a generalization of what we already have: our existing / default thumbnail_target_* would be thumbnail_target_python in this refactored code. Is that correct?

If so, then this sounds like a nice, reasonable generalization of #313. Then perhaps the nbconvert-based "thumbnailing"/running code could live as hopefully simple extensions in https://github.com/sphinx-gallery/sphinx-gallery-extra. WDYT?

(This would allow SG to stay relatively lean and backward compatible, and s-g-e could have the heavier CI dependencies needed to test and build the docs for the nbconvert-based extensions.)

This new proposal looks like a generalization of what we already have: our existing / default thumbnail_target_* would be thumbnail_target_python in this refactored code. Is that correct?

indeed, that could be 1 implementation.

Then perhaps the nbconvert-based "thumbnailing"/running code could live as hopefully simple extensions in https://github.com/sphinx-gallery/sphinx-gallery-extra. WDYT?

That might be a good idea. I'll keep that in mind. My focus is to get something lightweight working, with minimal code and effort.

My focus is to get something lightweight working, with minimal code and effort.

Unfortunately this will probably conflict with the refactoring idea, since I think it would be a bit of effort to get all of the interfaces/APIs right at the Sphinx-gallery end in the first place (i.e., just supporting the existing Python workflows properly). For long-term sustainability it would be nice to avoid people having to fork and/or copy-paste bits of sphinx-gallery to get the functionality that they need. So hopefully we can make it work at some point!

Absolutely agree that would be perfect, but I cannot make promises. The most practical solution for me is I push this to a repo, but not release on PyPI yet, or just deprecate the package once it lands in sge.

Just a note that this is one reason we created sphinx-gallery-extra...it's a place to play around with useful-but-less-stable code, require more complex dependencies, not support as many older versions of python, etc. Happy to iterate on contributions there @maartenbreddels

@maartenbreddels not sure if you are still working on this or have new ideas, but basically I lay out a plan in #441 (comment) about how we can support other modules. Basically the idea is to keep code for other scrapers in the modules that need scraping as much as possible, and "just" ensure that SG provides the interfaces necessary to do so.

I think this is perhaps the direction we were already headed with the discussion here. If you have an idea for how the APIs of SG would need to be generalized for ipyvolume, let me know. I'm happy to work on a general SG interface that would enable you to code the ipyvolume-specific bits so that people can do gallery_conf['image_scrapers'] = ['ipyvolume'] (or so) to use ipyvolume with sphinx-gallery!