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

Duplicate Entries in Download as Menu #938

Closed
hansen-m opened this issue Jan 3, 2019 · 7 comments · Fixed by #1027
Closed

Duplicate Entries in Download as Menu #938

hansen-m opened this issue Jan 3, 2019 · 7 comments · Fixed by #1027
Labels

Comments

@hansen-m
Copy link

hansen-m commented Jan 3, 2019

After updating to the latest version of nbconvert I'm seeing duplicate entries for the exporters in the Download as menu. Any way I can remove or manage these? I'm running JupyterHub via Anaconda 3.

screen shot 2019-01-03 at 13 45 11

@justmarkham
Copy link

I experienced the same behavior when I upgraded from nbconvert 5.3.1 to 5.4 (and that is the only thing I changed in my environment).

@t-makaro
Copy link
Contributor

t-makaro commented Apr 11, 2019

Dev note: Jupyter notebook added support for custom exporters in the menu here. This added a export _from_notebook to allow custom exporters to be added to the menu. #759 Documented that change in nbconvert, and #864 added export_from_notebook to the built-in exporters (which then resulted in the built-in exporters being duplicated in the menu). I believe. This could be fixed, by reverting #864, or on the notebooks side.

@MSeal
Copy link
Contributor

MSeal commented Apr 12, 2019

Hmm @t-makaro is right about the cause, I'm not sure what the intended pattern for UIs is supposed to be here. @mpacer @SylvainCorlay do either of you know those expectations better / can suggest the best change to make here?

@mpacer
Copy link
Member

mpacer commented Apr 15, 2019

So this seems to be an issue on the notebook side rather than on nbconvert's side. Notebook has hardcoded values back in the days when nbconvert didn't make these as easily visible.

The template that has the hardcoding is here:

https://github.com/jupyter/notebook/blob/eea37a6b2110e0b8a5491f17e241fa3c8aecb5f7/notebook/templates/notebook.html#L113-L126

The logic for getting exporters lives in get_custom_frontend_exporters here:

https://github.com/jupyter/notebook/blob/eea37a6b2110e0b8a5491f17e241fa3c8aecb5f7/notebook/notebook/handlers.py#L18-L28

The jinja rendering that populates that template with the exporter names and display names is in the same file as the get_custom_frontend_exporters definition:

https://github.com/jupyter/notebook/blob/eea37a6b2110e0b8a5491f17e241fa3c8aecb5f7/notebook/notebook/handlers.py#L59

@mpacer
Copy link
Member

mpacer commented Apr 15, 2019

Note this doesn't really solve the problem for 3rd party registered exporters; if they inherit from the existing nbconvert exporters, they will have the same export_from_notebook value and so it will produce additional duplicates, even if we get rid of the hard-coded redundant parts in notebook itself.

See jfbercher/jupyter_latex_envs#44 as an example of how that can be fixed

@MSeal MSeal added the upstream label Apr 15, 2019
@t-makaro
Copy link
Contributor

This is a bit of a hack (define __getattribute__ in the base exporter), but we could force export_from_notebook, not to be inherited by a subclass. That way by default subclassed exporters will not appear in the list without defining it themselves.

@t-makaro
Copy link
Contributor

Or, on the notebook side the get_custom_frontend_exporters could check if export_from_notebook is the same as the one defined by the superclass, and then ignore it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants