Validate cross-compatibility of jupyter(lab)-lsp

[bollwyvl]

Elevator Pitch

Determine an approach for validating jupyterlab-lsp's bottom pin on jupyter-lsp.

Motivation

Over on conda-forge we raised the discussion of what jupyterlab-lsp's proper bottom pin should be.

Design Ideas

• jupyter-lsp >={{ hand-made version }} (status quo)
  • we have to remember to bump the pin when something (e.g. schema, etc) changes
• jupyter-lsp
  • probably not so good, you kinda never know what you're going to get
• jupyter-lsp ==<latest>
  • probably not so good, means we can't ship a jupyter-lsp without shipping a new jupyterlab-lsp
  • hasn't happened yet, but a hotfix might need it

whatever we do, we could add a (nightly CI) test which validates a broader matrix of as-installable packages. i really don't know what we'd find... the most likely thing would be bumping a pin, and having to cut a new release, as at least on pip, yanking is not a great option. on conda-forge we can cut a build with an incremented build_number, but this doesn't always solve the problem.

[krassowski]

The status quo is being handled by:

https://github.com/krassowski/jupyterlab-lsp/blob/a823c987b4c6d14dc755a6976e8a77f1f6bac774/scripts/integrity.py#L257-L262

which reminds me each Sunday that I could increase the bottom version of jupyter-lsp. Maybe it should generate some clever GitHub Actions annotation to show up prominently on CI (without failing a build).

My manual decision process is to bump the pin on minor releases but not on patch releases as in major.minor.patch.

[bollwyvl]

Yeah, thoughtful is probably the best we can do at this point without actually testing old versions. At least we're looking! But seems like we really can't double (or worse) our CI time by testing the bottom pin every push. Since we're building noarch on conda-forge (and noarch we should stay as long as possible!) it can't help out much (e.g. by testing the oldest version and the newest version).