closes #1776 to make tag/tags in markdown work with jupytext #1780
Conversation
|
| @@ -43,7 +43,7 @@ Here's an example of adding this tag with a {myst:directive}`code-cell` directiv | |||
|
|
|||
| ````markdown | |||
| ```{code-cell} | |||
| :tags: raises-exception | |||
| :tag: raises-exception | |||
There was a problem hiding this comment.
I think jupytext uses tags, rather than tag. Though it does use square brackets for multiple tags.
https://jupytext.readthedocs.io/en/latest/formats-markdown.html
My feeling is that we should define the syntax we want for MyST, and then upstream the improvements to jupytext to make it work, rather than the other way around
There was a problem hiding this comment.
I checked by running examples that "tag" works for a single string while "tags" requires brackets in jupytext.
I think it's important to keep documentation in sync with reality as much as possible. I was asked to help, and changing the docs is all I am qualified to do.
There was a problem hiding this comment.
Can we change this all to tags: [raises-exception], that should work in both myst and jupytext correct?
There was a problem hiding this comment.
More broadly, options should be parsed as YAML if we're inheriting the spec from myst-parser / myst-nb, etc. I'm broadly in favour of this, because we already use YAML in other user-facing places, and it's a well-known standard to point to.
So, even if we don't actually use yaml.load, I'd like us to use the same standard. Therefore, we should treat tags: "" as something that we upgrade and deprecate.
As for tag -- it's not something we supported in myst-nb, so it's really just a question of whether we want more configuration or not. I'm tempted to not support it yet, because we don't have to.
Closes #1776