-
Notifications
You must be signed in to change notification settings - Fork 106
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
Linting and formatting notebooks #45
Comments
Some followup on how best to incorporate this into the workflow... As mentioned above, I think the code formatting (i.e. As a first step, a CI job that fails when things aren't formatted properly is fine, as maintainers can always tell/help contributors lint their code (run @harshal-dupare who has expressed interest in the infrastructure 🎉 . Feel free to comment/ask questions in this thread or open new issues as you see fit! |
There have been some previous discussions on how best to handle tasks like linting and formatting the notebooks. For example - we'd like to have the code cells formatted (e.g. via
black
) and have the markdown cells respect line character limits. Ultimately, I think we'd like to be able to incorporate automated linting/formatting to the workflow so that authors don't have to think about it at all. This issue is for starting the discussion on how best to do that.These topics have been discussed in other communities as well, most notably in mwouts/jupytext#432. There are some really nice ideas there. Fortunately, it looks like
jupytext
has built-in support for applyingblack
to code cells. In our case (with.md
-formatted notebooks) this would look like:I've tried this out a bit and it seems pretty robust - I think we could incorporate this into the workflow (maybe via pre-commit + a "style" CI job, similar to how NetworkX does it) relatively easily.
Formatting the non-code-cell markdown is a bit trickier. There is a suggestion from that same jupytext issue (mwouts/jupytext#432 (comment)) to try
pandoc
which has support for softbreaks (i.e. line breaks in source files) and automatically applies this formatting:This kind of works, but doesn't inherently support/recognize all the features of MyST markdown. For example, when I tried this on one of our notebooks, it dropped the footnotes. This seems like a reasonable approach, but it's not suitable (in the current state) for incorporation into an automated workflow.
The text was updated successfully, but these errors were encountered: