Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upDependencies between kernel execution and UI #4623
Comments
This comment has been minimized.
This comment has been minimized.
Speaking as a developer on nteract and having fresh in mind why people elected building new APIs and UIs for jupyter, the reason you don't want your JS API exposed in outputs is for your own sanity. Someday you're going to want to change an API and you will be locked into past decisions or have to go the route of breaking things. My opinion on the best way to handle this is to define metadata for the message spec for this. Note -- this use case is pretty similar to the proposal from @BoPeng in #4550 |
This comment has been minimized.
This comment has been minimized.
Yes, Kyle makes excellent points that explain our thinking on this. The
other thing we have considered is exposing the JupyterLab commands (which
are a much more narrow, and public "API" of JupyterLab) as a MIME output.
Then, kernels could send declarative JSON to run JupyterLab commands, but
no passing of JavaScript would be required.
…On Wed, May 23, 2018 at 12:26 PM, Kyle Kelley ***@***.***> wrote:
Speaking as a developer on nteract and having fresh in mind *why* people
elected building new APIs and UIs for jupyter, the reason you don't want
your JS API exposed in outputs is for your own sanity. Someday you're going
to want to change an API and you will be locked into past decisions *or*
have to go the route of breaking things.
My opinion on the best way to handle this is to define metadata for the
message spec for this. Note -- this use case is pretty similar to the
proposal from @BoPeng <https://github.com/BoPeng> in #4550
<#4550>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4623 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABr0AkzKptQnPaFQ3Z3d4V_UN3XRDJvks5t1bfagaJpZM4UK0jT>
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com
|
This comment has been minimized.
This comment has been minimized.
This sounds a lot like the now deprecated "payloads" feature of jupyter messages. Learning how it was added and deprecated could help the discussion here. |
This comment has been minimized.
This comment has been minimized.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion. |
During our meeting today, I brought up a request I had seen a couple of times (#4580, #3692) asking to be able to trigger some JupyterLab specific UI as the notebook executes. In this case, it was popping out an output into another window. Once the Javascript extension is merged (#4515), it would technically be very easy to provide Javascript output with a reference to the global application instance, which would let users do anything they want with in the JupyterLab frontend.
However, the consensus is that building official support for this would encourage creating notebooks that are JupyterLab specific and wouldn't be able to be supported by other frontends like nteract. The recommended approach is to create an extension, if you want to access the jupyterlab API.
In this case, it could possibly be an extension that handles a new mimetype by creating a new window for it and language specific wrappers that wrap outputs in this new mimetype. That would be easier for other frontends to also handle.
It would be good to document this rationale somewhere, maybe in the larger context of what features should be built into core vs what are better suited to third party extensions (at least at first).
EDIT: I am collecting issues that I think are related to this question of kernel execution being dependent on the frontend here: