Update jupyter-client requirement from <8 to <9 #1728
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
|
|
|
@dependabot rebase |
brichet
force-pushed
the
dependabot/pip/jupyter-client-lt-9
branch
from
ab1b7b5 to
f21b6a3
Compare
|
A newer version of jupyter-client exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged. |
Updates the requirements on [jupyter-client](https://github.com/jupyter/jupyter_client) to permit the latest version. - [Release notes](https://github.com/jupyter/jupyter_client/releases) - [Changelog](https://github.com/jupyter/jupyter_client/blob/main/CHANGELOG.md) - [Commits](jupyter/jupyter_client@4.0.0...v8.0.1) --- updated-dependencies: - dependency-name: jupyter-client dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
brichet
force-pushed
the
dependabot/pip/jupyter-client-lt-9
branch
from
f21b6a3 to
944e79e
Compare
|
I looked into why this is failing and hit a couple dead ends. I'll come back to it later, but I don't really know where to proceed other than filing various bug reports. The problem lives in
For a reason I have yet to understand, that default doesn't propagate down to If I hardcode the value of |
When upgrading the dependency spec to include v8, some python tests broke (see jupyter#1728). The tests were failing with a timeout due to indefinitely blocked IO. This originates in an infinitely-looping notebook and is caused by a misconfiguration of the client connection. Currently using `nbclient.NotebookClient` with a `jupyter_client.manager.KernelManager` results in a deadlock. nbclient doesn't seem aware of this issue because there is no test covering it. `NotebookClient` uses `AsyncKernelManager` by default. So why isn't nbgrader using it? nbgrader uses the NotebookClient via nbconvert which just realized the same issue. Up until v7.3.1, nbconvert has been hard-coding the default kernel manager to the sync version. (see jupyter/nbconvert#1964) Rather than require nbconvert>=7.3.1, this commit sets our own default value to the async kernel manager.
|
Closed in favor of #1778 |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
When upgrading the dependency spec to include v8, some python tests broke (see jupyter#1728). The tests were failing with a timeout due to indefinitely blocked IO. This originates in an infinitely-looping notebook and is caused by a misconfiguration of the client connection. Currently using `nbclient.NotebookClient` with a `jupyter_client.manager.KernelManager` results in a deadlock. nbclient doesn't seem aware of this issue because there is no test covering it. `NotebookClient` uses `AsyncKernelManager` by default. So why isn't nbgrader using it? nbgrader uses the NotebookClient via nbconvert which just realized the same issue. Up until v7.3.1, nbconvert has been hard-coding the default kernel manager to the sync version. (see jupyter/nbconvert#1964) Rather than require nbconvert>=7.3.1, this commit sets our own default value to the async kernel manager.
When upgrading the dependency spec to include v8, some python tests broke (see #1728). The tests were failing with a timeout due to indefinitely blocked IO. This originates in an infinitely-looping notebook and is caused by a misconfiguration of the client connection. Currently using `nbclient.NotebookClient` with a `jupyter_client.manager.KernelManager` results in a deadlock. nbclient doesn't seem aware of this issue because there is no test covering it. `NotebookClient` uses `AsyncKernelManager` by default. So why isn't nbgrader using it? nbgrader uses the NotebookClient via nbconvert which just realized the same issue. Up until v7.3.1, nbconvert has been hard-coding the default kernel manager to the sync version. (see jupyter/nbconvert#1964) Rather than require nbconvert>=7.3.1, this commit sets our own default value to the async kernel manager.
When upgrading the dependency spec to include v8, some python tests broke (see jupyter#1728). The tests were failing with a timeout due to indefinitely blocked IO. This originates in an infinitely-looping notebook and is caused by a misconfiguration of the client connection. Currently using `nbclient.NotebookClient` with a `jupyter_client.manager.KernelManager` results in a deadlock. nbclient doesn't seem aware of this issue because there is no test covering it. `NotebookClient` uses `AsyncKernelManager` by default. So why isn't nbgrader using it? nbgrader uses the NotebookClient via nbconvert which just realized the same issue. Up until v7.3.1, nbconvert has been hard-coding the default kernel manager to the sync version. (see jupyter/nbconvert#1964) Rather than require nbconvert>=7.3.1, this commit sets our own default value to the async kernel manager.
Updates the requirements on jupyter-client to permit the latest version.
Release notes
Sourced from jupyter-client's releases.
Changelog
Sourced from jupyter-client's changelog.
... (truncated)
Commits
9904c41Publish 8.0.1dc6113cFix json_output in kernelspec app (#921)dac3cc2Publish 8.0.0760a783MAINT: Don't format log in log call. (#919)0ab0febReflect current protocol version in documentation (#918)eded331Add full api docs (#908)0d62b85Sync lint deps (#911)3161087Remove deprecated zmq imports (#915)d6890f2MAINT: consistently use relative imports. (#912)f556b00[pre-commit.ci] pre-commit autoupdate (#909)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)