Keep a way to opening a notebook with the default renderer without uninstalling the extension

[fperez]

Describe the bug

context

For being able to test this extension in a hosted hub, it's critical that I can switch back and forth between the MystJS renderer and a "normal" view with the default one, as was possible til 0.1.2.

If we notice problems with mystjs, right now we have no option but to entirely uninstall it and redeploy into production, which is a huge barrier.

I'm happy to tell students to occasionally switch to the old renderer manually if necessary, but having to redeploy makes it impractical to test/use the tool while it matures in a production environment.

Reproduce the bug

Once installed, mystjs takes over completely all notebook rendering.

List your environment

No response

[agoose77]

Could you clarify your needs here? If it is just that you have an immutable environment (e.g. from a Docker image), you shouldn't need to uninstall the extension to disable it: one can run jupyter labextension disable jupyterlab-mystjs.

[rowanc1]

The PR / discussion that introduced this is here:
#17 (comment)

I wonder if it was a bit premature to fully take over the renderer. The terminal approach might be a bit much for students at the moment, I think there is a disable extension UI in Jupyter4.0?! Can't wait :)

[fperez]

Yup, our students don't control the startup of the environment itself, so the approach that was there in 0.1.2 was just about right. They could choose which to use, but it's too much for me in class to be telling them to basically reconfigure the server every time they log in.

[fperez]

I'm already pushing the limits of dog-fooding in a real-world course, I need to keep my focus on actually teaching a class :)

[fperez]

Though thanks @agoose77 for the labextension disable tip - I'd forgotten about it, and while not the answer I need for this particular scenario, it can be a good solution for other cases! Much appreciated.

[agoose77]

@fperez so you need the ability to switch off the MyST renderer in some contexts during the same session? Could you elaborate on why you need this, is it just missing features?

[fperez]

Yup, precisely - the way it worked originally.

Right now if there's any bug/mismatch in this renderer compared to the default, escaping out is tricky. I'm using a real-world course to test this, so I need my students to very easily fall-back (within the same session they are working on) to the default renderer at any sign of trouble.

[agoose77]

Are you using .ipynb notebooks, or jupytext-backed Markdown notebooks?

[fperez]

.ipynb notebooks for the most part.

[agoose77]

OK. My take (not the only one that matters by any stretch of the imagination) is that the majority of our users at this stage should be using jupyter labextension disable ... to turn on/off the renderer. This is because we integrate much better with the rest of the JupyterLab tools in doing so.

However, I can see that your use case is trickier because of this, so perhaps we can find a compromise; a second, mutually exclusive JupyterLab extension (shipped in this repo) that restores the old behaviour. This would be opt-in for you, so you can configure your binder image such that the old behaviour is the default.

[fperez]

Yup, I'm happy to do that - I have full control over my hub config so I can add any extension the team offers, as long as it has that functionality.

Thx!!

[rowanc1]

Other approaches could be:

1. to revert parts of the update, and keep the PR waiting in the wings while we improve the extension so that the fallback becomes less and less required?
2. Provide a setting to toggle the behaviour?

I think at this stage we are already have jupyterlab-mystjs and jupyterlab-myst -- my goal this week was to reduce myst extensions in the wild not add more. :)

I am not sure if (2) is easily possible, but would love to see settings start to emerge in this extension, so that could be a way to get into doing that!

[agoose77]

@rowanc1 on terminology, in the JupyterLab context an "extension" is just a re-usable unit of code that integrates with the dependency injection system. We can ship multiple in the same package. I think we might be able to e.g. trigger a setting, but the user would also need to reload the page. I can see why that would be a poor UX if @fperez wants students to be able to do this multiple times in a session :/

I'll push a PR that we can bikeshed :)

[rowanc1]

Ok, awesome. Mostly trying to avoid having more pip/npm/conda packages out there. Looking forward to seeing what you come up with, thanks @agoose77. Let me know when I can help out!

[agoose77]

BTW @rowanc1 is there a feeling that we'll use an organisation package name here, e.g. @executablebooks/jupyterlab-mystjs?

[rowanc1]

TL;DR: I think we should stick with a flat namespace (no @ team) in the JS world.

We debated this a lot with the myst-to-html myst-to-jats naming conventions, different communities take different approaches to this. What I like about the 'flat' namespace is that there is no distinction between an official extension and a community extension, and that speaks a bit more to our values I think. I like that for things that should in-principle work together on equal footing (e.g. in prosemirror).

I think there is a different approach if there is a collection of packages that must all be installed together to work, this is the approach that we are taking for @myst-theme (and in @jupyterlab and many other tighter-knit packages).

[rowanc1]

@fperez, @agoose77 fixed this up in a PR, I want to get the HTML parsing working and then will aim to cut another release this afternoon!

• Add html handling to markdown cells #36

[fperez]

Fantastic, I'll push to our hub once it's on PyPI and will keep reporting. I immensely appreciate the team's hard work, I'm very excited about working this semester with MyST with our students - thx @agoose77 for the responsiveness!