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

* -> ipynb converter #4930

Open
5 tasks
jdfreder opened this issue Jan 29, 2014 · 3 comments
Open
5 tasks

* -> ipynb converter #4930

jdfreder opened this issue Jan 29, 2014 · 3 comments
Milestone

Comments

@jdfreder
Copy link
Member

Migrated from https://github.com/ipython/nbconvert/issues/96


Meta issues to track the other format we would like to convert from

  • rst
  • markdown
  • knitr ?
  • .py
  • other propriatary format?
@bollwyvl
Copy link
Contributor

bollwyvl commented Nov 8, 2014

More as a lark than anything else, I started a general implementation of nbconvert importers, with an initial markdown importer:
https://github.com/bollwyvl/ipython/tree/markdown-importer

It borrows most of its implementation language from the exporters.

This one handles:

  • markdown(!)
  • indented code blocks
  • fenced code blocks (with language hint, which it optimistically turns into a magic)
  • doctests in either of the above

There are some strange things happening:

ipython nbconvert --to notebook --from markdown notebook1.md

You get, as one might expect, notebook1.md.ipynb and notebook1.md.nbconvert.ipynb.
If you run it again, you start getting notebook1.md.ipynb.nbconvert.ipynb. Haven't figured that out yet.

Interested in feedback, will PR if there is interest.

@minrk
Copy link
Member

minrk commented Nov 9, 2014

I think we probably should add the notion of a Reader or Importer (whatever we end up calling it) to nbconvert. I think we should not add this functionality before splitting nbconvert into its own standalone project.

@damianavila
Copy link
Member

It is funny that nbconvert start standalone and will be standalone again... jeje... regarding the issue itself, I think that the Reader/Importer is a need for the future... some random thought for the future... I think we need to keep the symmetry in the exportation/importation cycle...

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

No branches or pull requests

5 participants