Skip to content

ipywidgets expects Comm, not BaseComm #1090

Closed

Description

@matthewturk

Hi! I've been trying to track down an issue with my usage of ipywidgets, described on discourse. The basic gist is:

  • I'm attempting to create a widget from the client by using a model.widget_manager's method new_widget. In previous versions, this worked, but now, it doesn't.
  • The issue seems to stem from the kernel attempting to create a new comm instance for a widget, but supplying to that widget a BaseComm rather than a Comm, which throws a validation error.

After digging through this, it looks to me like ipywidgets declares comm = Instance('ipykernel.comm.Comm', allow_none=True), but ipykernel.ipkernel.create_comm explicitly creates a BaseComm, so the traitlet doesn't validate, and the comm fails to properly initialize. This results in the widgets not being synced back to the kernel from the frontend.

I confess that while I've spent time going through the code, I'm not entirely sure if this could potentially be a version mismatch, or if this is an oversight for a use case that may not come up terribly frequently.

My versions:

  • ipywidgets - 8.0.4
  • ipykernel - 6.21.1
  • comm - 0.1.2

I was able to address the problem I was having by changing the import and usage of BaseComm to Comm in ipkernel.py, and so if this is an acceptable solution I'd be happy to issue a pull request. (My hesitance is that there may be unexpected downstream effects of a change to something so deep in the kernel code, and so I wanted to open the issue as possible first step.)

Activity

  1. blink1073 commented on Feb 8, 2023

    @blink1073
    Contributor

    Hi @matthewturk, please do open a PR. We test most known downstream consumers in Jupyter and spyder, seeing if those downstream tests fail would be a good indicator.

  2. maartenbreddels commented on Feb 8, 2023

    @maartenbreddels
    Contributor

    I think this is an ipywidget issue.

    @matthewturk In jupyter-widgets/ipywidgets#3602 (comment) I removed the comm being an Instance of this class. I think this will fix it, but we never merged it.

  3. matthewturk commented on Feb 8, 2023

    @matthewturk
    Author

    @maartenbreddels That PR is pretty big though -- does it need to be a part of that, or would a smaller PR that simply loosened restrictions work, so that we don't have to pin all our dependencies to a lower version?

  4. maartenbreddels commented on Feb 8, 2023

    @maartenbreddels
    Contributor

    I think if we just cherry-pick, jupyter-widgets/ipywidgets@c1c34f9 we should be able to get this in sooner.

    An even saver option, it to change it to traitlets.Any. I don't think we need the type safety for the comm.

  5. martinRenou commented on Feb 10, 2023

    @martinRenou
    Contributor

    I will work on finishing jupyter-widgets/ipywidgets#3533 this morning. This PR uses traitlets.Any and we should backport it to ipywidgets 7

  6. maartenbreddels commented on Feb 10, 2023

    @maartenbreddels
    Contributor

    I think we should backport this indeed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions