Skip to content
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

"No renderer could be found for output" message in outputs #6216

Closed
BenRussert opened this issue Apr 18, 2019 · 14 comments · Fixed by #6559
Closed

"No renderer could be found for output" message in outputs #6216

BenRussert opened this issue Apr 18, 2019 · 14 comments · Fixed by #6559

Comments

@BenRussert
Copy link

@BenRussert BenRussert commented Apr 18, 2019

Describe the bug
When using the scrapbook package, the glue function anywhere in a cell produces a confusing message:

No renderer could be found for output. It has the following MIME types: application/scrapbook.scrap.json+json

No outputs are expected for the glue function alone.

To Reproduce
Steps to reproduce the behavior:

# !pip install nteract-scrapbook
import scrapbook as sb
sb.glue("hello", "world")

or

# in the same cell:
x = "world"
sb.glue("hello", x)
x

You would expect "world" in output, but not the message. The message is prepended however:

Screenshots

jupyter-lab-no-render-message

Expected behavior
No output or warning message

@jasongrout jasongrout added this to the Reference milestone Apr 18, 2019
@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 18, 2019

It sounds like this would be a great mimerender extension to provide a renderer for this mimetype. I'm a little surprised that scrapbook doesn't seem to provide a text/plain representation to show in frontends that don't understand that mimetype.

@MSeal
Copy link

@MSeal MSeal commented Apr 18, 2019

Since the display type is meant to recall data pragmatically, it doesn't give a plain text mimetype representation. Scraps with display contents (like images) will give the normal mimetype representations one would expect to render. None of the jupyter interfaces currently render the scrapbook data mimetype, but it might be interesting to enable such rendering at some point in the future to view the data. It's intended purpose is to allow for capturing data or references to data in the notebook object that can be recalled by another process, thus an invisible rendering was the original approach.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 18, 2019

Ah, thanks. So what I'm hearing is that JupyterLab shouldn't try to be helpful here in rendering an error?

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 18, 2019

(I'll note for myself and others that the message spec only mandates text/plain in mimebundles in a pager or execution_result message, not in display_data messages)

@jasongrout jasongrout removed this from the Reference milestone Apr 18, 2019
@jasongrout jasongrout added this to the 1.1 milestone Apr 18, 2019
@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 18, 2019

No output or warning message

Sorry, I think I misread the desired behavior above. It seems the answer is: "yes, don't render any output or error."

Bumping to a good first issue for 1.0.

@jasongrout jasongrout removed this from the 1.1 milestone Apr 18, 2019
@jasongrout jasongrout added this to the 1.0 milestone Apr 18, 2019
@MSeal
Copy link

@MSeal MSeal commented Apr 18, 2019

Yep, was just giving some context. The "yes, don't render any output or error." is correct.

@MSeal
Copy link

@MSeal MSeal commented Apr 18, 2019

Thanks!

@saulshanabrook
Copy link
Member

@saulshanabrook saulshanabrook commented Apr 22, 2019

@jasongrout So to be clear, is your suggestion that if we cannot find any renderer, we simply don't render an output instead of displaying this error message?

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 22, 2019

@jasongrout So to be clear, is your suggestion that if we cannot find any renderer, we simply don't render an output instead of displaying this error message?

Correct (which is what was asked in the OP as well as asked by @MSeal).

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 27, 2019

This is now marked as a good first issue. The error message is generated at

widget.node.innerHTML =
`No ${model.trusted ? '' : '(safe) '}renderer could be ` +
'found for output. It has the following MIME types: ' +
Object.keys(model.data).join(', ');

@vidartf
Copy link
Member

@vidartf vidartf commented Apr 28, 2019

Maybe it still makes sense to display this message if the notebook is not trusted, and a valid renderer would have been available if it was?

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Apr 29, 2019

Maybe it still makes sense to display this message if the notebook is not trusted, and a valid renderer would have been available if it was?

That makes sense to me. In that case, the error message should probably reflect the idea that the trust status caused it not to render.

@saulshanabrook
Copy link
Member

@saulshanabrook saulshanabrook commented May 22, 2019

The classic notebook does not create an output div when there is no renderer available. The consensus in the meeting is that we should do the same, if we cannot render an output, then we could not create a div.

But this might be slightly painful to change, based on Phosphor messages lining up with DOM children. For 1.0, it would be good to look into this change.

For now, to get around this, you could try outputting a text/plain with an empty body.

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Jun 12, 2019
… types.

Fixes jupyterlab#6216

This does render a div for outputs corresponding to things we can’t render, since we need the list of widgets to correspond to the output messages.
@lock
Copy link

@lock lock bot commented Aug 6, 2019

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.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants