-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Multiple outputs for e.g. webpdf, pandoc #46
Comments
I don't have strong opinions about this but I'd love to get the input from the upstream devs of nbconvert. (I'm guessing you are one of them, right?) Can you bring this up with them and get their opinion on this? |
From the nbconvert issue, we've got one 👍 from the most active maintainer... we can let it cook for a while, but i can knock together a wip PR... |
If the most active maintainer is happy, go for it! |
Welp, here we go: #47 |
Hey folks!
Over on conda-forge/staged-recipes#12516 (comment) we've been chatting about the tradeoffs of offering a
jupyter-book-webpdf
, which would be somewhat simpler if there was annbconvert-webpdf
which already carried thepyppeteer
pin, beyond whatrun_constrained
would do.However we solve it over there, we could take the opportunity to offer, a la
matplotlib[-base]
nbconvert-core
(which could benoarch: python
) that still carried all therun_constrained
pieces, but was lighter-weight and -featured (pandoc should be an optional, not required, dependency #24)nbconvert
that actually requiredpandoc
, and therefore could not benoarch: python
, for nownbconvert-webpdf
that acutally requiredpyppeteer
, and could actually also benoarch: python
It would take a while (or maybe a migration) to get everything that didn't specifically need the
pandoc
capability to use-core
, but eventually, maybe, (more) people could be happy(er).I'm happy to work up a PR if people think this is a good idea.
The text was updated successfully, but these errors were encountered: