On Mon, Jul 01, 2024 at 12:55:49PM +0100, Colin Watson wrote:
> Control: block 1059658 by 1071879
>
> Hi,
>
> I was looking at the RC bug https://bugs.debian.org/1059658, and I
> noticed that there've been unreleased commits in
> https://salsa.debian.org/python-team/packages/jupyter-client for months
> that seem to fix this.
>
> However, when I ran the autopkgtests for that version locally I found
> that they're a mess, with lots of repeats of this (trimmed for
> readability):
>
> jupyter_client/__init__.py:3: in <module>
> from .asynchronous import AsyncKernelClient
> jupyter_client/asynchronous/__init__.py:1: in <module>
> from .client import AsyncKernelClient # noqa
> jupyter_client/asynchronous/client.py:12: in <module>
> from ..client import KernelClient, reqrep
> jupyter_client/client.py:20: in <module>
> from .connect import ConnectionFileMixin
> jupyter_client/connect.py:22: in <module>
> from jupyter_core.paths import jupyter_data_dir, jupyter_runtime_dir,
> secure_write
> /usr/lib/python3/dist-packages/jupyter_core/paths.py:208: in <module>
> deprecation(
> /usr/lib/python3/dist-packages/jupyter_core/utils/__init__.py:90: in
> deprecation
> warnings.warn(message, DeprecationWarning, stacklevel=stacklevel + 1)
> E DeprecationWarning: Jupyter is migrating its paths to use standard
> platformdirs
> E given by the platformdirs library. To remove this warning and
> E see the appropriate new directories, set the environment variable
> E `JUPYTER_PLATFORM_DIRS=1` and then run `jupyter --paths`.
> E The use of platformdirs will be the default in `jupyter_core` v6
> _internal = ['jupyter_core/']
> internal = 'jupyter_core/'
> message = 'Jupyter is migrating its paths to use standard
> platformdirs\ngiven by the platformdirs library. To remove this
> warni...TER_PLATFORM_DIRS=1` and then run `jupyter --paths`.\nThe use of
> platformdirs will be the default in `jupyter_core` v6'
> stacklevel = 2
>
> Now, tests/conftest.py does in fact set JUPYTER_PLATFORM_DIRS=1, so I
> think the problem is that the autopkgtests run "$py -m pytest
> jupyter_client" rather than just "$py -m pytest". But that has a
> different problem:
>
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
> 865, in import_plugin
> __import__(importspec)
> ModuleNotFoundError: No module named 'pytest_jupyter'
>
> And:
>
> # apt install python3-pytest-jupyter
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> Unsatisfied dependencies:
> python3-pytest-jupyter : Depends: python3-jupyter-core (>= 5.7) but
> 5.3.2-2 is to be installed
> Error: Unable to correct problems, you have held broken packages.
>
> So I guess this is https://bugs.debian.org/1071879, and presumably the
> easiest way out would be to upgrade jupyter-core to a current upstream
> version. Any objections to me going ahead and doing that?
>
> I'm also a bit confused as to how it got this way. Julian must have
> been able to build pytest-jupyter in order to construct the upload in
> https://tracker.debian.org/news/1518227/accepted-pytest-jupyter-091-1-source-all-into-unstable/,
> but a sufficient version of jupyter-core wasn't in unstable then any
> more than it is now. Was this hacked up locally in some way?
Hi Colin,
You are indeed correct. I have locally built several jupyter
packages, but discovered that there is a huge tree, and that it pretty
much all needs updating together; here are some of the packages that
need updating or introducing to Debian (some of which are required for
tests and others for documentation building):
jupyter-client 8.6.0
\- jupyter-core 5.7.2
\- pytest-jupyter
jupyter-server 2.13.0
\- jupyter-events 0.10.0
\- rfc3339-validator
\- python-strict-rfc3339
\- rfc3986-validator
\- python-fqdn
\- python-isoduration
\- python-overrides
\- rfc3339-validator
\- python-strict-rfc3339
\- rfc3986-validator
\- jupyter-server-terminals
\- pytest-console-scripts
\- sphinxcontrib-github-alt
\- sphinxcontrib-openapi
\- sphinx-mdinclude
\- picobox
\- sphinxcontrib-emojicodes (sphinxemoji)
\- python3-traitlets (>= 5.6.0) - uploaded, but now breaks jupyter-notebook
\- pytest-mypy-testing
(Some of the jupyter-events dependencies are optional dependencies of
jsonschema required by jupyter-events, but the Debian jsonschema
package does not depend on them and neither does the current
jupyter-events.)
jupyter-notebook 7.1.2
\- jupyterlab >= 4.1.1, <4.2
\- jupyter-lsp - see below
\- jupyterlab_server >= 2.22.1
\- openapi_core
\- openapi-schema-validator
\- jsonschema-path
\- pathable
\- aioitertools
\- openapi-spec-validator
\- autodoc-traits
So far, the situation is that I have uploaded all of the new packages
listed here to NEW, except for openapi_core, which I hope to do this
week (its test suite depends on an updated version of python3-parse,
against which I've submitted an ITS), and jupyter-lsp - see below.
Except for those listed under jupyter-notebook, everything has been
accepted to unstable and most have now migrated to testing (where that
is possible).
I have not yet pushed any of my local work on the jupyter* packages to
salsa or upload to experimental, but that will be the next step.
In the meantime, the wonderful JavaScript folk (including Yadd and
Roland, copied in to this), have been looking at the JavaScript parts
of jupyter-notebook and jupyterlab.
jupyter-lsp is part of jupyterlab-lsp, which is a large "package"
including two Python packages (jupyter-lsp and jupyterlab-lsp) and a
number of JavaScript packages. That still needs to be looked at.
(I'm also very unclear why jupyterlab depends on jupyter-lsp but not
jupyterlab-lsp; the latter depends on the former.)
Once that's all done, we should be able to update the whole stack, but
it may take a while still.
But if someone has a suggestion of doing things differently, for
example, updating jupyter-core, jupyter-client and jupyter-server
(along with jupyter-event) now, and just leaving jupyter-notebook and
jupyterlab until they're ready, that would be fine too.
I hope this makes some sense!
Best wishes,
Julian
