JupyterLab 3 support v2

[krassowski]

Probably should have rebased rather than merging, but let's roll with this. Opening as new PR for now to spin the CI, but we might sent a PR to #402 instead. Relates to #400.

python -m pip install -e . --ignore-installed --no-deps -vv
jupyter serverextension enable --py jupyter_lsp
jupyter labextension develop . --overwrite

Punchlist:

• setup new branch for JupyterLab 2.x and make RTD build another version of docs for it so that we can point users who will stick with 2.x for the time being (https://github.com/krassowski/jupyterlab-lsp/tree/2.x)
• fix the docs
• decide whether to publish both npm and python package or only one of those
  • probably npm is needed too as otherwise confused users will see message that this version of lab is not supported and we have no way of telling them from the interface that they need to use pip only this time.
• typescript 4.1.3
• eslint:

    "@typescript-eslint/eslint-plugin": "^4.8.1",
    "@typescript-eslint/parser": "^4.8.1",
    "eslint": "^7.14.0",
    "eslint-config-prettier": "^6.15.0",
    "eslint-plugin-jest": "^24.1.3",
    "eslint-plugin-prettier": "^3.1.4",
    "eslint-plugin-react": "^7.21.5",

• In the CONTRIBUTING.md:
  • the proposed pip install . needs to be invoked after every change, after compilation. This is extremely tedious and needs automation. jupyter labextension build and jupyter labextension develop . --overwrite
    to the rescue?
• releasing instructions update
• update issue templates
• verify on

[krassowski]

A small conda dependency hell for Python 3.6 it looks like. Did JupyterLab 3.0 drop 3.6?

[bollwyvl]

In the doit-based automation I've been doing (ha) around lab3 on other extensions, the approach I'm somewhat happy with is:

• do a "normal" install by default (just to ensure it works)
• encapsulate the whole watch process in a separate command, out at the python level, which does the appropriate setup, runs the watches, etc. then kills both of them when either dies

I've been finding this easier to reason about.

On CI: node on windows (and even OSX) is boring when it breaks, as now we don't really care if webpack works on those platforms. I've been building the wheel/sdist up-front in a build job, and installing them in the test job. This helps catch subtle file omissions that the symlink thing sweeps under the covers. We may want a separate package.json of just our npm-distributed language servers, which would be the only thing that's installed on the various test boxen, but wouldn't be installed on the build box. On a local dev enviornment, you'd need both, of course.

Testing: the modal command palette is kinda flaky under test (10% of the time, it seems to just disappear, depending on what has focus when invoked). The original sidebar behavior that is easy to test (and works with our existing stuff) can be restored by settings:

    Create File
    ...    ${SETTINGS DIR}${/}@jupyterlab${/}apputils-extension${/}palette.jupyterlab-settings
    ...    {"modal": false}

[bollwyvl]

A small conda dependency hell for Python 3.6 it looks like. Did JupyterLab 3.0 drop 3.6?

this weirdness:
https://github.com/conda-forge/jupyter_server-feedstock/blob/master/recipe/meta.yaml#L19

Will get on it...

[bollwyvl]

Have some PRs up, one of which I can't merge (jupyter_server) but hopefully can be resolved quickly...

[bollwyvl]

Some notes:

• we should probably update the tagline

Multi-Language Server WebSocket proxy for Jupyter Notebook/Lab server
                                                          ^
                                                    Maybe just "Server"?

[bollwyvl]

jupyter-lsp >1.0.0 does not match 1.0.0rc0, which fails pip check and likely means that someone would not get anything if they tried to pip install jupyterlab-lsp... can work around in conda, but...

• we should add this to integrity
• we should add pip check to CI

[bollwyvl]

• the rcs went out without tags
  • we need to decide how we're going to do tags in the future, e.g. jupyterlab-like
    • v3.0.0 is also...
      • release/jupyterlab-lsp/1.0.0
      • release/jupyter-lsp/2.0.0
    • or give up, and do CalVer...

[bollwyvl]

conda-forge/jupyter-lsp-feedstock#8

[bollwyvl]

Theoretically should work (within the hour):

[bollwyvl]

Well, it built, but the serverextension is not enabled, because binder is running under notebook + nbclassic, not straight-up jupyter_server. I don't think this is going to be a long-term problem, so I'm willing to roll with it: so, no blockers from the conda side.

[krassowski]

Added integrity checks and removed rc tags. If it passes I will upload new version and merge.

Where would the pip check go?

[krassowski]

Added pip check to job.test.yml though earlier I was thinking about keeping it in build (which would require to install packages there too I guess)

[bollwyvl]

Added pip check to job.test.yml

Yeah, sorry, mean to actually PR these things, got caught up in local election coverage 😊.

Also, as we ran into a similar packaging issue over on jupyterlab-classic once it got to conda (this happens all the time), I PRd some stuff to do a relatively lightweight check over there... I can adapt it here.

Basic idea: do just a run of the packages, as built, with just setup-python (no node, conda) and do the CLI smoke tests, as they seem. Will get a PR up, but might not be able to finish it.

[bollwyvl]

#456 smoke tests are green, so probably ready to merge in here. Slowest one was 6 minutes, so not going to bother with caching pip.

[lresende]

Any eta for a working rc?

[krassowski]

1-2 hours for PyPI release, some time more until conda packages catch up. I will do one final push and publish the new release once CI passes.

[lresende]

Thank you @krassowski

[krassowski]

@lresende the release is fully out now. Please see: https://github.com/krassowski/jupyterlab-lsp/releases/tag/v3.0.0 for update instructions