Skip to content

Conversation

@erawn
Copy link

@erawn erawn commented Nov 12, 2025

This is a PR to propose adding cell_meta to ExecutionInfo so that IPython extensions can utilize it. This PR builds on 1169 which passed cell_meta to the kernel, and adds it as an optional field in ExecutionInfo which is then passed to run_cell. Other half on the ipykernel side is here

My own personal use case (and the one I would imagine most have for this), is building IPython extensions which pair with extended/customized frontend clients. Personally, I've had to do some rather messy hacks in order to run an IPython and JupyterLab extension which can communicate, and for anything more than a prototype it would be valuable to have a way to append information to the execution requests directly that can be seen by extensions. Since cell_meta already extends the metadata field in the Jupyter Messaging protocol, this seemed like the most natural way to go about it.

As discussed here when cell_id was introduced, there was talk of refactoring into a more general metadata field, but it seems the current decision is to keep both cell_id and cell_meta. This PR would extend that decision and continue passing cell_meta.

I'm interested in feedback on what would be most useful to others or if there are decisions we can make now that support the most flexibility long-term. Continuing on with cell_meta as I've done here wouldn't introduce any breaking changes, and so seems the most straight forward, but I'm curious what others think. Thanks!

@erawn erawn changed the title [WIP] add cell_meta to ExecutionInfo and pass through run_cell add cell_meta to ExecutionInfo and pass through run_cell Dec 10, 2025
@erawn
Copy link
Author

erawn commented Dec 10, 2025

Because the default for cell_meta is already None, I've kept that default and changed the existing instance where the default was an empty dictionary.

Btw, using empty dictionaries as default arguments is warned against in the docs so it seemed reasonable to stick with None as the default.

Copy link

@rodrigosf672 rodrigosf672 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for these changes, @erawn. The more I understood about them, the more appreciate the value of this contribution.

Non-blocking question: since cell_meta becomes part of the public execution path, do you think it’d be worth adding a brief docstring note about its expected use and structure? Even one sentence might help extension authors discover it. If you think that'd be a good idea, I can address it as a separate issue/PR.

Again, thanks so much for this contribution and for being so open about getting feedback from the Jupyter community. :)

@erawn
Copy link
Author

erawn commented Dec 11, 2025

Thank you so much for your help! You've made my first IPython pull request a really lovely experience :)

Happy to add the docstring—is the most recent change I've made what you had in mind? The docstring for run_cell seems to be where most of the documentation is that I can see, but if there is a better place just let me know.

Copy link

@rodrigosf672 rodrigosf672 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's great! The wording is clear and I think it should be helpful for extension authors. Thank you so much, and congrats on your first IPython pull request!! 🙌

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants