Steven Silvester

I agree with @telamonian's assessment.

As an example, we're using JupyterLab 1.x at AWS, and planning to wait until 3.0 is released to upgrade, since we decided that the 2.0 release did not have enough...

> OK so you are saying we should allow minor releases on older major versions? Yep, that's what I'm advocating for.

Specifically `pip debug` didn't work, ongoing testing is in that linked PR.

I don't have the bandwidth to debug, but we are in fact ignoring GitHub links already https://github.com/jupyterlab/maintainer-tools/blob/5de3cd5d1953dce710fff2cf16a576ea209b9d3f/.github/actions/check-links/check_links.py#L34

Yes, the asyncio logic is definitely convoluted, I'm working on a fix in https://github.com/jupyter/jupyter_client/pull/997, but I haven't had much bandwidth recently.

I don't think the issue is with that code block per se, because the effect is that it is not actually sending, because `send_multipart` returns an awaitable for an async...

We're already handling this in several other downstream consumers, e.g. https://github.com/jupyter-server/jupyter_server/blob/f6b732c652e0b5a600ff0d3f60c6a34173d8d6a5/pyproject.toml#L145. I think that is part of the responsibility of handling warnings as errors.

Hi @vdyashin, it looks like the matlab engine itself is not properly installed, which is required by the kernel. https://www.mathworks.com/help/matlab/matlab-engine-for-python.html.

No, sorry, I don't have a Matlab license. You'd have to ask MathWorks technical support (I'm not affiliated with them).