-
Notifications
You must be signed in to change notification settings - Fork 950
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace ipykernel dependency by the comm dependency #3811
Replace ipykernel dependency by the comm dependency #3811
Conversation
3a2fb0e
to
49e9036
Compare
CI failure is due to the Notebook 7 release |
def create_comm(**kwargs): | ||
from ipykernel.comm import Comm | ||
|
||
return Comm(**kwargs) | ||
else: | ||
from comm import create_comm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
I'll test this today! |
@martinRenou this was more difficult to get right, the comm module could be imported, and ipykernel count not (yet) be imported (as is the case for solara). Also, by putting the same API in a shim module, I think it cleaned up the code a bit. What do you think? |
from ipykernel.comm import Comm | ||
|
||
return Comm(*args, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really like to get rid of this some day.
That way we can remove the nasty patches of ipykernel.comm in xeus-python.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you want to get rid of this? in xeus-python you don't need to fix this right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's say a library imports ipykernel and we import it before ipywidgets, then we end up in this block, breaking xeus-python. So xeus-python needs to patch this import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only for old ipykernels right? Do you think that will still happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like this piece of code to basically stay around forever, so we better get it right! :)
We can also skip this if we can detect xeus-python, or some other condition to make this more robust? Do you make use of a 'fake' ipykernel module in xeus-python?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only for old ipykernel yes.
I'd like this piece of code to basically stay around forever
Let's talk again about it in ten years? 😄
Do you make use of a 'fake' ipykernel module in xeus-python?
Yeah we mock the ipykernel module https://github.com/jupyter-xeus/xeus-python/blob/main/src/xinterpreter.cpp#L77 . We should keep this mock in xeus-python for supporting old ipywidgets anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to discuss this in ten years from now :)
Yes putting it all in a separate file makes sense. Thanks for looking into it! I need to check that this works nicely with xeus-python. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with xeus-python, it works nicely! Thanks @maartenbreddels
🎉 |
meeseeksdev please backport to 7.x |
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the If these instructions are inaccurate, feel free to suggest an improvement. |
… comm dependency
Backport PR #3811: Replace ipykernel dependency by the comm dependency
ipywidgets 8.1.0 has been released, which includes the change at jupyter-widgets/ipywidgets#3811. With this change, ipykernel is no longer a dependnecy of ipywidgets, so jupyer-sphinx must now depend on ipykernel directly rather than assume it will be installed as a transitive dependency of ipywidgets. Without this change, jupyter-sphinx tests will fail CI. This has additionally led to CI failures in some packages that depend on jupyter-sphinx but not ipykernel.
hello, with the backport of this to 7.X, it means now that ipywidgets 7.X is not working anymore on python 3.6 (as the comm module will require traitlet >= 5, which require python >= 3.7). Is it intended that ipywidgets 7.X won't support python 3.6 ? thanks |
Thanks for commenting. We can probably loosen the Traitlets dependency in the comm package in a patch release. Would you like to open a PR for this? |
I don't think I'll have the time soon, but here's another proposal: ipython/comm#15 |
This broke https://ipywidgets.readthedocs.io/en/stable/try/lab/index.html?path=Widget%20List.ipynb ---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
Cell In[2], line 1
----> 1 import ipywidgets as widgets
File /lib/python3.10/site-packages/ipywidgets/__init__.py:54
51 return
52 register_comm_target()
---> 54 _handle_ipython()
File /lib/python3.10/site-packages/ipywidgets/__init__.py:52, in _handle_ipython()
50 if ip is None:
51 return
---> 52 register_comm_target()
File /lib/python3.10/site-packages/ipywidgets/__init__.py:41, in register_comm_target(kernel)
39 """Register the jupyter.widget comm target"""
40 from . import comm
---> 41 comm_manager = comm.get_comm_manager()
42 if comm_manager is None:
43 return
File /lib/python3.10/site-packages/ipywidgets/comm.py:18, in get_comm_manager()
17 def get_comm_manager():
---> 18 if requires_ipykernel_shim():
19 ip = get_ipython()
21 if ip is not None and getattr(ip, "kernel", None) is not None:
File /lib/python3.10/site-packages/ipywidgets/comm.py:11, in requires_ipykernel_shim()
8 if "ipykernel" in sys.modules:
9 import ipykernel
---> 11 version = ipykernel.version_info
12 return version < (6, 18)
13 else:
AttributeError: module 'ipykernel' has no attribute 'version_info' Some ways forward:
As this isn't a part I've monkied with much, would appreciate some insight from those that have, but would happily do the PR. Also, worrying about python 3.6, and frankly, 3.7, is getting a bit wearisome if it can lead to any problems for folks that are on currently supported pythons. |
We've been discussing this in #3819
I think that' the way to go for now, longer term we get rid of the shim and use the comm module only.
I'm surprised, using the comm module to expose the pyolite's implementation of the comms should be almost straightforward.
What do you mean about this? Related, it has been raised that comm could not be installed on Python 3.6 due to a strict traitlets dependency, it has been fixed in comm 0.1.4 by loosening the traitlets dependency. |
Well actually jupyterlite/pyodide-kernel#53 (comment) |
As discussed in #3749
This will: