Get the list of exporters from entrypoints #3879
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`exporter_map` is deprecated, so let's use the list of exporters fetched from the installed entrypoints. There's a supposed attribute `export_from_notebook` that should be set to a friendly string name if the exporter should be exposed in the front-end. However, the exporters defined in `nbconvert` don't have it set, so I haven't used it to determine inclusion in the list. Instead, I've used the entrypoint name as the friendly name, which looks like it was the intention from the way they are named. I ran the unit tests and tried starting up the notebook server and accessing the API endpoint to verify the JSON looked correct.
|
The JSON from my test run at http://localhost:8888/api/nbconvert looks like this: {
"asciidoc": {
"output_mimetype": "text/asciidoc"
},
"custom": {
"output_mimetype": ""
},
"html": {
"output_mimetype": "text/html"
},
"latex": {
"output_mimetype": "text/latex"
},
"markdown": {
"output_mimetype": "text/markdown"
},
"notebook": {
"output_mimetype": "application/json"
},
"pdf": {
"output_mimetype": "text/latex"
},
"python": {
"output_mimetype": "text/x-python"
},
"rst": {
"output_mimetype": "text/restructuredtext"
},
"script": {
"output_mimetype": ""
},
"slides": {
"output_mimetype": "text/html"
}
} |
starcruiseromega
added a commit
to starcruiseromega/nbconvert
that referenced
this pull request
Aug 25, 2018
I was working on jupyter/notebook#3879 and it looks like the intended way to determine whether the exporter should show up in the list generated by the notebook server was by checking `export_from_notebook`, but it isn't defined for any of the builtin exporters. The docs also say this specifies a friendly name for the exporter. In the PR mentioned above, I used the name defined by the entrypoint to key the exporter. It sounds like maybe we should use the value in `export_from_notebook` instead, so I've made them match, but perhaps it's confusing to have a "name" for the entrypoint in two places.
|
I opened jupyter/nbconvert#864 to add the |
|
This is great, thank you! |
This was referenced Sep 24, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
exporter_mapis deprecated, so let's use the list of exporters fetchedfrom the installed entrypoints.
There's a supposed attribute
export_from_notebookthat should be setto a friendly string name if the exporter should be exposed in the
front-end. However, the exporters defined in
nbconvertdon't have itset, so I haven't used it to determine inclusion in the list. Instead,
I've used the entrypoint name as the friendly name, which looks like it
was the intention from the way they are named.
I ran the unit tests and tried starting up the notebook server and
accessing the API endpoint to verify the JSON looked correct.