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

Get the list of exporters from entrypoints #3879

Merged
merged 1 commit into from Sep 7, 2018

Conversation

Projects
None yet
2 participants
@starcruiseromega
Contributor

starcruiseromega commented Aug 25, 2018

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.

Get the list of exporters from entrypoints
`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.
@starcruiseromega

This comment has been minimized.

Contributor

starcruiseromega commented Aug 25, 2018

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

Add export_from_notebook
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.
@starcruiseromega

This comment has been minimized.

Contributor

starcruiseromega commented Aug 25, 2018

@starcruiseromega

This comment has been minimized.

Contributor

starcruiseromega commented Aug 25, 2018

I opened jupyter/nbconvert#864 to add the export_from_notebook so that we could get rid of that XXX. I'm not sure if, in that case, it's better to use the value of export_from_notebook as the name in the list instead of the entrypoint name, so I'd be happy to have some guidance on that. :)

@minrk

This comment has been minimized.

Member

minrk commented Sep 7, 2018

This is great, thank you!

@minrk minrk merged commit 6c0ee1b into jupyter:master Sep 7, 2018

4 checks passed

codecov/patch 75% of diff hit (target 0%)
Details
codecov/project Absolute coverage decreased by -0.3% but relative coverage increased by +0.95% compared to 98085dc
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@minrk minrk added this to the 5.7 milestone Sep 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment