Skip to content

Complete ipynb export support #1915

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

Merged
merged 5 commits into from
May 23, 2025

Conversation

kp992
Copy link

@kp992 kp992 commented Mar 12, 2025

Hi,

I am trying to complete the feature in #1882. And building my first PR on top of it. I tried to add the ipynb writer by visiting the blocks and merging all the markdown blocks to a single cell until a code cell appears. Please review the PR.

I have a small question:
How do I test it using a CLI locally for a single file? I currently do npm run test from myst-to-ipynb directory. Is there a way I can test some ast.yml or .md file to ipynb?

I am sorry if this is a very newbie question and documented somewhere.

Copy link

changeset-bot bot commented Mar 12, 2025

⚠️ No Changeset found

Latest commit: 1975f85

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@kp992 kp992 changed the title fix some tests and comment the failing ones to fix in upcoming commits Complete ipynb export support Mar 12, 2025
@kp992 kp992 marked this pull request as draft March 12, 2025 01:23
@kp992
Copy link
Author

kp992 commented Mar 27, 2025

@rowanc1 I have added/fixed the test cases from your PR. Should I work on capturing more metadata and output of the cells in the same PR or the follow up is okay?

@agoose77 agoose77 changed the base branch from main to myst-to-ipynb April 2, 2025 07:44
}

if (md_cells.length != 0) {
cells.push(markdownString(file, md_cells));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kp992 this is a "policy" decision to fuse Markdown cells. Is there a particular reason for doing this? With the base PR #1882, if you ingest an ipynb file and export an ipynb, then you'll end up with the same number of cells (perhaps the frontmatter might be moved, though).

If you have a use-case for fusing Markdown cells, I'd suggest adding that as an option!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this and reviewing the PR. I was actually in a confusion splitting at \n may break the code where the string contains \n. But we do have an escape character added before that after parsing so that should not be any issue. I tried that case works fine with the splitting logic so I will put that logic back. I have also updated the tests according to that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think these changes need reverting. Consider the following Markdown notebook

---
kernelspec:
  name: python3
  display_name: Python 3
---

```{code-cell} python3
import sys
```

+++ { "kind": "notebook-content" }
Desc 1

+++ { "kind": "notebook-content" }

Desc 2

```{code-cell} python3
import os
```

It's the MD equivalent of having four cells:

  • code
  • md
  • md
  • code

In this PR, that gets flattened to

  • code
  • md
  • code

(and the myst-to-md also writes the block separator +++ inside the cell, which is not quite right).

Can you elaborate on why you made this particular change? Did the original PR fail to convert something properly?

@agoose77
Copy link
Contributor

agoose77 commented Apr 2, 2025

@rowanc1 I have added/fixed the test cases from your PR. Should I work on capturing more metadata and output of the cells in the same PR or the follow up is okay?

I've changed the base of this PR so that it will be merged into the original PR. If the original PR changes, we'll need to rebase this one first. So, the goal should be to get this one over the line ASAP by keeping it small! The test changes are welcome — I haven't looked at them in any detail, but it would be wonderful to get the test suite passing. If you have time to address my query about the fusing of Markdown cells, we can then look at what needs to be done to close this out and open a follow-up PR if needs be!

@kp992 kp992 requested a review from agoose77 April 3, 2025 01:43
@kp992
Copy link
Author

kp992 commented Apr 15, 2025

@agoose77 Can you please review it once? Thanks in advance

Copy link
Contributor

@agoose77 agoose77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the tests @kp992! I made some comments about some of the changes that we would probably like to revert, etc.

}

if (md_cells.length != 0) {
cells.push(markdownString(file, md_cells));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think these changes need reverting. Consider the following Markdown notebook

---
kernelspec:
  name: python3
  display_name: Python 3
---

```{code-cell} python3
import sys
```

+++ { "kind": "notebook-content" }
Desc 1

+++ { "kind": "notebook-content" }

Desc 2

```{code-cell} python3
import os
```

It's the MD equivalent of having four cells:

  • code
  • md
  • md
  • code

In this PR, that gets flattened to

  • code
  • md
  • code

(and the myst-to-md also writes the block separator +++ inside the cell, which is not quite right).

Can you elaborate on why you made this particular change? Did the original PR fail to convert something properly?


type TestCase = {
title: string;
markdown: string;
ipynb: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't care about the exact text representation of the ipynb file on disk. Could you change the ipynb entry to be a Record<string, any>?

Then, you'd need to update the tests to be

- title: link reference
  mdast:
   type: root
   children:
     - type: text
       value: markdown
  ipynb: 
    cells:
      - 

instead of

- title: link reference
  mdast:
   type: root
   children:
     - type: text
       value: markdown
  ipynb: |-
      {
        "cells": [

This would enable us to write the regression test in YAML (less verbose) and to choose to omit parts of the output that we don't want to test (e.g. if there were timestamps)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review @agoose77. I have update the code and a couple of test cases. I this looks good, I can uncomment and work on other test cases.

@kp992 kp992 requested a review from agoose77 May 9, 2025 01:16
@agoose77
Copy link
Contributor

Thanks for the work here @kp992! I'm going to merge this into the other PR, and review the result there!

@agoose77 agoose77 marked this pull request as ready for review May 23, 2025 18:57
@agoose77 agoose77 merged commit 407689a into jupyter-book:myst-to-ipynb May 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants