Jlab extensions that target both jlab3 and jlab4

JupyterLab extensions
1

I am currently following at least 2 extensions that have moved from jlab3 to jlab4, namely jupyterlab-myst and jupyterlab-jupytext

the former have managed to produce a code that works in both jlab3 and jlab4, using for example this kind of code (the metadata access API change is the one that has the greatest impact)

it feels like it is indeed much simpler, in terms of development, to end up with a single code base, rather than e.g. 2 distinct branches, and/or to resort to dependency management to pick the right version of the extension (is that even doable ?) but your mileage may vary

in any case I guess this triggers the questions :

  • is there a better way to probe for the currently running jlab version ?
  • and more generally what is the general approach recommended to extension writers, in order to deal with compatibility with jlab major releases ?

also, if you know of such an extension, please point us to it :slight_smile:

4 Likes
2

following up on my own post, I went ahead and tried something a little bit different for jupytext here

EDIT
https://github.com/mwouts/jupyterlab-jupytext/pull/8

after a few mishaps the latest attempt eventually ended up here

this is no long term solution: the type-checker is systematically fooled, and code is really not good-looking
but it should allow to ship quickly, and so with minimal changes, an extension that can work under both versions

I’d love to hear if there were better approaches

3

update:

the initial idea of writing

    JLAB4 = new SemVer(app.version).compare('4.0.0') >= 0;

does not work for two reasons:

  • superficially, release candidates would come with app.version like e.g. 4.0.0rc0, which is not semver-friendly, we would need to feed it with 4.0.0-rc0 instead (hyphen is mandatory), as per
    Semantic Versioning 2.0.0 | Semantic Versioning
  • more serious, in the context of nb7 the app object seems to refer to the notebook app instance, and so here we get 7.0.0rc0 instead as app.version

so this approach is wrong, need to find something better…

4

To differentiate between notebook and jupyterlab you could use app.name.

5

I’m working on JupyterLab 4 compatibility for Jupyter Scheduler, and I’m curious about how to handle the dependencies. Currently, Jupyter Schedule depends on @jupyterlab/filebrowser version 3. How can I use both version 3 and 4, with the appropriate call made depending on the JupyterLab version that the user has?