-
Notifications
You must be signed in to change notification settings - Fork 44
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
Document new mdformat-pyproject
plugin
#379
Comments
Thanks for building the plugin! 🥳
I don't have the time right now, but might be able to have a look in the future.
A PR to add your plugin to the docs is very welcome! You may also want to consider adding this topic https://github.com/topics/mdformat to your project to make it more discoverable. |
Thanks @hukkin ! I'll try to make a PR adding the plugin sometime soon. BTW: I just realized I forgot to link the plugin in the initial message. I just embedded it in the message, but here it is again for anyone looking for it: |
Context
I created this plugin that lets
mdformat
load options from a[tool.mdformat]
section inside thepyproject.toml
file, if it exists. This basically covers the need exposed in #356 without having to make any modification to the core ofmdformat
and therefore not binding the project to any particular project type.The
pyproject.toml
file is found relative to each file that is processed, and relative tocwd
ifstdin
contents are being parsed. This is the same behavior as with.mdformat.toml
.Also, if
.mdformat.toml
exists, its options are also loaded, giving precedence to thepyproject.toml
ones if an option exists in both places (basically,.mdformat.toml
is loaded first as usual, and then thepyproject.toml
update whatever options were already loaded).About the implementation
The implementation is slightly hacky, because it imports
mdformat
internals and forces the parsing and validation of CLI arguments twice in order to honor them, but I could not figure out a better way to achieve this without including some modification inmdformat
to keep track of what the original CLI args were.@hukkin If there is a cleaner or most robust way to achieve the same results I will happily hear that and adapt. Maybe #378 can also be considered along the way, so we can basically unify how the options and CLI arguments are handled in away that lets the plugins alter that if necessary (to either add options, or load the options from somewhere else).
Proposal
Add this plugin to the list in the docs. I'm happy to make a PR for that if this is accepted.
Tasks and updates
The text was updated successfully, but these errors were encountered: