-
Notifications
You must be signed in to change notification settings - Fork 168
Quickstart Guide and MyST-NB implementation #2362
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
Conversation
for more information, see https://pre-commit.ci
…cels into MyST-quickstart to add in precommit fixes
|
I managed to build the docs using MyST-NB and I think the docs look pretty good, which I think is exciting! The main observations I have so far:
|
This reverts commit 9e8f25d. refactor in a different PR
for more information, see https://pre-commit.ci
Sorry - slightly confused with the terminology - by 'notebook' do you mean actual notebook ( |
Yes, I meant the markdown file with executable cells. I have written the quickstart tutorial in this format and I like writing in markdown, but I have still written it much like I would write a Jupyter Notebook. I like the consistency and integration with the rest of the documentation website, but it is helpful to be able to execute the cells as I am writing them to see that the result is as I expect, which is a Pro for Jupyter Notebooks. |
|
Noting that:
|
…cels into MyST-quickstart
|
Perhaps also change the name of this PR to better reflect what it is (the QuickStart guide and the myST-nb implementation)? |
Co-authored-by: Erik van Sebille <[email protected]>
for more information, see https://pre-commit.ci
…cels into MyST-quickstart
VeckoTheGecko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I missed the discussion - why the verbose_progress=False?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about hard wrapping of prose in markdown files @reint-fischer ? Is that also something to mention here?
(e.g.)
I can write a whole paragraph on one line, but it becomes a bit difficult to read when suggesting edits via GitHub, or depending on your editor settings. When rendered in the docs site, it doesn't matter if this is spread along multiple lines (as long as there is no blank line in between). If you roughly spread it across multiple lines then working with diffs becomes easier.
I can write a whole paragraph on one line, but it becomes a bit
difficult to read when suggesting edits via GitHub, or depending
on your editor settings. When rendered in the docs site, it
doesn't matter if this is spread along multiple lines (as long
as there is no blank line in between). If you roughly spread it
across multiple lines then working with diffs becomes easier.
We could go to the extreme and enable this via a pre-commit hook, but that would be quite messy and unnecessary I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I am not opposed to that, I can add a recommendation; is there a specific length you like?
Parcels/docs/development/docsguide.md
Line 44 in 3c9447a
| - We recommend hard wrapping prose in markdown so that reading it becomes easier in any editor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
90ish
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After editing a few files I am a bit more skeptical; adding and removing wrapping for entire paragraphs seems quite cumbersome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair - maybe just something to be aware of that you can hard wrap items if you want to and it wont change rendering in the final markdown. Doesn't have to be a hard style guide. Feel free to mention it how you want in the style guide, or not at all - that's fine too
Co-authored-by: Nick Hodgskin <[email protected]>
Thanks for bringing this up, it was a temporary fix for the way |
|
🥳 |
Implementing
MyST-NBas a sphinx extension will replace bothnbsphinxandmyst_parser. This way, we can read and execute both.mdand.ipynbnotebooks, which will allow us to write new notebooks in.mdfor better integration with the rest of the documentation.TODO
myst_nbremovemyst_parser.ipynbexecution fromnbspinxtomyst_nbFixes #2335