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.

Sign up for GitHub

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

Jump to bottom

✨ NEW: Add myst_extensions configuration option #9

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

✨ NEW: Add myst_extensions configuration option #9

wants to merge 1 commit into from

Conversation

chrisjsewell
Copy link
Member

No description provided.

@chrisjsewell chrisjsewell requested a review from hukkin June 23, 2021 16:04
@chrisjsewell chrisjsewell linked an issue Jun 23, 2021 that may be closed by this pull request
Strategy for optional MyST syntax #5
Open
@chrisjsewell
Copy link
Member Author

Meh, this isn't strictly possible at the moment, because the CLI enforces that all plugins have to be used, and I want to be able to select what ones are activated.

@hukkin
Copy link
Member

hukkin commented Jun 23, 2021 •
edited

Yeah there is no easy way to disable other installed plugins. But with dollarmath for example, which is a part of this particular plugin, there should be no problem having this feature.

As discussed in #5 my take is still that it may be better to just install additional syntax separately, but now after the ownership transfer you no longer have to care what I think 😄

Btw why does MyST have "optional but on by default" syntax"? To me it would feel intuitive if any syntax that's on by default is "core" MyST syntax. EDIT: this is off topic, I made an issue in myst-parser for this executablebooks/MyST-Parser#399

@chrisjsewell
Copy link
Member Author

chrisjsewell commented Jun 23, 2021 •
edited

it’s just a pain, because it means that every small extension (like dollarmath and substitutions that are like 3 lines of code) has to have its own package.
I also think it would be nice if it was easy for users to align the formatting with their myst configuration, without having to worry about setting up loads of extension installs, possibly even just allowing for this extension to read directly from conf.py (or jupyter-book’s config) to decide how to configure the formatter; that would be most user friendly for a sphinx project, and avoid duplication of config

but now after the ownership transfer you no longer have to care what I think 😄

oh no I still expect your input 😜

why does MyST have "optional but on by default" syntax"?

well that’s only dollarmath, which is more of a legacy thing and so a bit of a pain to deprecate. There’s also the balance of wanting it to be easy for users to align with the default Markdown of Jupyter Notebooks.

@chrisjsewell chrisjsewell mentioned this pull request Jun 23, 2021
Closed
@chrisjsewell
Copy link
Member Author

Would you consider having some small hook in mdformat, to allow a plugin to decide if another should be activated/deactivated for the CLI?

@hukkin hukkin mentioned this pull request Jun 23, 2021
Open
@hukkin
Copy link
Member

hukkin commented Jun 23, 2021

Would you consider having some small hook in mdformat, to allow a plugin to decide if another should be activated/deactivated for the CLI?

Perhaps if we can't think of a workaround and if there's a nice and simple enough way to do the hook. I made an issue in mdformat

@hukkin
Copy link
Member

hukkin commented Jul 1, 2021 •
edited

Do you think adding a --enabled-syntax (override) or --disabled-syntax to mdformat core would suit your needs? Stuff like dollarmath could then be kept in this repository but in a separate plugin module/class (one repo can have many) and can be disabled on the command line if need be. That would avoid special casing MyST syntax (as it really isn't special, and much of it is used outside MyST context).

I also think it would be nice if it was easy for users to align the formatting with their myst configuration, without having to worry about setting up loads of extension installs, possibly even just allowing for this extension to read directly from conf.py (or jupyter-book’s config) to decide how to configure the formatter; that would be most user friendly for a sphinx project, and avoid duplication of config

I think splitting syntax into separate distributions and using .pre-commit.config.yaml is a pretty good way to do mdformat configuration and delegate the extension installs to a tool that does it well. Then Python env is always clean, and additional_dependencies is configuration like any other. I'm not very excited about reading another tool's configuration. Actually I'm not a very excited about configuration in general 😄

Btw what's your thoughts on having something like mdformat-myst and mdformat-myst-full (as discussed in #5). Seems like a simple way to avoid configuration, and I doubt that any extra extensions enabled in mdformat-myst-full would hurt many users.

@hukkin
Copy link
Member

hukkin commented Jul 1, 2021

Btw one way to force what this PR tries to do is to make mdformat-myst a sort of an evil non-collaborative plugin that vendors mdformat-tables and mdformat-frontmatter dependencies so that it has direct control of all extensions.

Not saying I like the idea, but it definitely is a possibility, and can give you full control over everything, even allowing you to read whatever config files you want.

@arwedus
Copy link

arwedus commented Nov 24, 2021

@chrisjsewell I would like to follow up on this, because I am interested in getting mdformat running but we use colon-fence a lot. What is the current status? Would this be mergeable?

@chrisjsewell chrisjsewell mentioned this pull request Mar 4, 2022
Closed
jezdez added a commit to pyscript/pyscript that referenced this pull request May 12, 2022
@jezdez
Add section for mdformat but disable it for now.
fce1741 
See executablebooks/mdformat-myst#9 for more details.
@jezdez jezdez mentioned this pull request May 12, 2022
Merged
19 tasks
fpliger pushed a commit to pyscript/pyscript that referenced this pull request May 17, 2022
@jezdez @pre-commit-ci
@mattkram @ximena9201
Documentation infrastructure. (#262)
6898daf 
* Initial setup.

This does a few things:

- Adds some placeholders following the Diátaxis framework (https://diataxis.fr)
- Sets up Sphinx with MyST parser for Markdown in addition to rST.
- Uses the well-known PyData Sphinx theme.
- Moves some already existing Markdown files into the docs directory.
- Sets up the initial doc review GitHub action to auto-deploy to GitHub pages.

* Activate conda env.

* Remove custom action.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Make the dir.

* Push directly

* Add readthedocs config.

* Disable GitHub pages deployment for now.

* Add release and latest workflows as well.

* Make clear that this is work in progress.

* Made docs merge ready, added What is PyScript section with example.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Replace `on:tags:` with `on:create:`

The existing trigger is apparently not in the GHA spec

* Pretty format YAML

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* add s3 sync and permissions

* Leave status message in PR.

* Redirect from docs.pyscript.net/ to docs.pyscript.net/latest/

* Delete latest directory before deployment.

* Update review and release workflows, too.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Allow access to S3 for review and release doc workflow.

* Fix name of workflow.

* Bump up Python version.

* Because YAML.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Revert move to 3.10.

* Fix sitemap.

* Remove status settgin from release and latest build.

* Comment out cleanup.

* Add write permissions for statuses.

* More permissions?

* Fix artifact name.

* Use appropriate concurrency.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* .zip not needed

* Align name of workflows with CI workflows.

* Add checks permission.

* Set a notice instead.

* Move to sphinx-design.

* Add sphinx-autobuild.

* Use frontmatter more.

* Add section for mdformat but disable it for now.

See executablebooks/mdformat-myst#9 for more details.

* Fix fencing.

* Actually using html renderer.

* Revert moving governance files.

* Use full URLs for governance docs.

* Added warning.

* Fix copyright and author.

* Another minor fix.

* Use GitHub Action summary instead of notice.

* Fix variable name.

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Matt Kramer <mkramer@anaconda.com>
Co-authored-by: ximena9201 <ximenandrea.ro@gmail.com>
@dylan-thomas832 dylan-thomas832 mentioned this pull request May 26, 2022
Open
@hukkin hukkin mentioned this pull request Jun 27, 2022
Closed
@KyleKing KyleKing mentioned this pull request Jun 27, 2023
Closed
LecrisUT
LecrisUT reviewed Aug 9, 2023
View reviewed changes
mdformat_myst/plugin.py
extensions = set(arg.split(","))
unallowed_extensions = extensions.difference(SUPPORTED_EXTENSIONS)
if unallowed_extensions:
raise ValueError(f"Unsupported myst extensions: {unallowed_extensions!r}")
Copy link

Choose a reason for hiding this comment

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

Can this be made a warning instead of a hard error?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@LecrisUT LecrisUT LecrisUT left review comments

@hukkin hukkin Awaiting requested review from hukkin

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Strategy for optional MyST syntax
4 participants
@chrisjsewell @hukkin @arwedus @LecrisUT