Update the recommended JupyterLab version

[krassowski]

References

Follow-up after #275. Closes #289.

Code changes

• source of truth for JupyterLab version is now taken from packages, not from binder environment
• versions.py added to the root to ensure versions consistency across the repo
• Installation notebook now uses code cells with modified markdown magic to display the variables

User-facing changes

None

Backwards-incompatible changes

None

Chores

• linted
• documented

[bollwyvl]

sorry the version appears in so many places, looks like just readme and the lab.txt are
out of sync.

👍 to requiring lab 2.1, though!

[krassowski]

Would you think that converting the markdown cell in docs/Installation.ipynb to a code cell returning a markdown object, then hiding the code and only displaying the result would be possible/advisable? This would allow to having the versions from variables...

[bollwyvl]

Yeah, we could parse job.test.yml and pull out the "broadest" spec. Though looks like right now they are all set to >2,<3.0.0a0.

I think we have some other examples of using nbsphinx: source_hidden in some of the other notebooks... it's buried down the the metadata -> advanced sidebar in cell metadata.

[krassowski]

I think I found an elegant solution: spatialaudio/nbsphinx#81 (comment) :)

[krassowski]

So this still WIP, but 43a08ce is POC that it works. Just need to bump the JupyterLab version in the npm package and decide where to put the version and markdown cell code (which currently is in the notebook, but it certainly should go somewhere).

[krassowski]

I added versions.py in the root of the repo to track versions more reliably, with a single source of truth across the repo. CI now passes - apart from Windows being Windows.

[bollwyvl]

Now that all this (almost) works: I thought there were things (related to completion #239?) we definitely wanted from Lab 2.2.0... how might we validate that the features in question landed?

[krassowski]

This is a good question. I asked in the jupyterlab/jupyterlab#8080. There was also jupyterlab/jupyterlab#8375, none of which is in the final changelog. But then, the 2.2 release was a bit unusual...

[bollwyvl]

Thanks for the refs! Looks like both of them shipped:

• https://github.com/jupyterlab/jupyterlab/blob/v2.2.0/packages/completer/src/widget.ts#L422-L428
• https://github.com/jupyterlab/jupyterlab/blob/v2.2.0/packages/completer-extension/src/index.ts#L96-L99

[bollwyvl]

Hooray green CI! It seems like merging now, and doing the release dance, would make sense as 2.2.0 is not widely distributed. Then do the next release with the hard 2.2.0 dependency.

[krassowski]

Looks like it - thanks for checking! So my current plan is to:

• merge this PR
• fix /docs/LANGUAGESERVERS.md missing #254
• maybe fix Pyflakes (pyls) fails when '%' is present in notebook code #281
• Title tag for docs includes "0" instead of a release number #221: close or use versions.py to set version in the title
• release a final major version targetting JupyterLab 2.1 on Monday
• branch off
• star working on JupyterLab 2.2 completion (merge Integrate ICompletionItems #239)
• merge [wip] Add Language Server Proxy Kernel #278

Not sure where #288 would fit.

[bollwyvl]

merge #278

I'm super excited that you are interested in #278: we've been demoing with it on https://github.com/deathbeds/_fam/tree/07-11-2020 and it's been working pretty well. I've also been tinkering with a JEP to formalize the schema it uses.

Not sure where #288 would fit.

Let's not hold up anything for #288: it is, however, pretty important to some other stuff I'm working on (and getting paid for) so it will get finished, at some point. Presently, I'm still having issues getting it built on OSX, which is very hard to debug from a distance, but it won't actually have that big of an impact once it lands (would just be a small dot release of the server piece). Really getting it to work, though, will require a dedicated extension:

• with a full bundled pdf.js, a la jupyterlab-latex
• that can handle its custom LSP extensions 😿