-
Notifications
You must be signed in to change notification settings - Fork 84
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
BUG: Get eval results from metadata #597
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #597 +/- ##
==========================================
+ Coverage 80.97% 80.98% +0.01%
==========================================
Files 30 30
Lines 2702 2714 +12
==========================================
+ Hits 2188 2198 +10
- Misses 514 516 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@agoose77 is there a way this can make it into this week’s release? |
I will hold this for now; we need to rectify the different ways that myst-nb and jupyterlab-myst perform caching of output expressions. |
This just uses the user expression result that’s already stored in the metadata. It doesn’t touch how it’s being stored. That doesn’t seem to have a potential for problems, or am I missing something? |
My initial concerns were around the way that execution should be handled. But your choice of wording has helped me to disambiguate the two cases; reading from a notebook when execution is disabled is something that we can (and should) to. I'll revisit this PR shortly (probably next week). |
Hi, it’s been a month! Would be great if you could take a look here |
Thanks @flying-sheep for your continued patience. I want to add support for inline-expressions in |
Thanks for the update. I’d say merging this as-is would probably already add value, as it’s a tiny change with big effects. Do you know what adding support for jupyter-cache would entail? |
ping |
@flying-sheep I know that you've already committed a fair number of cycles to this and other PRs in the stack. Thanks for your on-going patience. I have clarified my qualms about merging this. I'd like to propose a change -- can you introduce a new executor class that subclasses the base executor, and move the expressions logic there? The intention is that other executors that don't support user expressions like |
Fixes #596
No idea how to elegantly pass the
SyntaxNode
all the way down to the role, and I’m not super interested in figuring that out, it’s your call how to implement that.