-
-
Notifications
You must be signed in to change notification settings - Fork 107
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
Is there any way to skip creating the markdown files and nav manually ? #179
Comments
I've been using this ugly Bash script myself: #!/usr/bin/env bash
cd src || exit 1
rm -rf ../docs/reference
mkdir ../docs/reference
find your_package | grep -v -e pyc\$ -e __pycache__ -e '^your_package$' -e py.typed -e __init__ -e __main__ | sort | while read -r line; do
indent="$(echo "${line}" | sed -r 's/\w+\// /g;s/[^ ]+$//')"
case "${line}" in
*.py)
mod=${line##*/}
line=${line%.py}
dot=${line//\//.}
md=${line#your_package/}.md
dir=${md%/*}
if [ ! "${dir}" = "${md}" ]; then
mkdir -p ../docs/reference/${dir}
fi
echo "::: ${dot}" > ../docs/reference/${md}
echo "${indent}- ${mod}: reference/${md}"
;;
*)
echo "${indent}- ${line##*/}:"
esac
done It will regenerate the We could consider allowing handlers to provide ways to do this (creating files with |
@pawamoy Thanks a lot. I was planning to write somekind of script. The script you shared, will perfectly do my work for now. Having some option in the cli would be great ! |
This will be even more relevant for Crystal handler because Crystal programming language tends to have a ton of classes, and the convention for docs currently is to put one class per doc page. See my script for generation in the commit message here: I think there could even be some generic MkDocs plugin for file generation, and it would actually work very well to just import and use |
This makes `handlers_cache` no longer be global but instead be confined to the Plugin. There will be only one instance of the plugin so it doesn't matter anyway. But actually this is also more correct, because what if someone tried to instantiate multiple handlers with different configs? It would work incorrectly previously. But my main goal for this is to expose `MkdocstringsPlugin.get_handler(name)`. Then someone can use this inside a mkdocs hook: def on_files(self, files: Files, config: Config): crystal = config['plugins']['mkdocstrings'].get_handler('python').collector So this is basically a prerequisite for issue mkdocstrings#179: one could query the collector to know which files to generate.
This makes `handlers_cache` no longer be global but instead be confined to the Plugin. There will be only one instance of the plugin so it doesn't matter anyway. But actually this is also more correct, because what if someone tried to instantiate multiple handlers with different configs? It would work incorrectly previously. But my main goal for this is to expose `MkdocstringsPlugin.get_handler(name)`. Then someone can use this inside a mkdocs hook: def on_files(self, files: Files, config: Config): crystal = config['plugins']['mkdocstrings'].get_handler('python').collector So this is basically a prerequisite for issue mkdocstrings#179: one could query the collector to know which files to generate.
This makes `handlers_cache` no longer be global but instead be confined to the Plugin. There will be only one instance of the plugin so it doesn't matter anyway. But actually this is also more correct, because what if someone tried to instantiate multiple handlers with different configs? It would work incorrectly previously. But my main goal for this is to expose `MkdocstringsPlugin.get_handler(name)`. Then someone can use this inside a mkdocs hook: def on_files(self, files: Files, config: Config): crystal = config['plugins']['mkdocstrings'].get_handler('python').collector So this is basically a prerequisite for issue mkdocstrings#179: one could query the collector to know which files to generate.
I am tackling this issue in a comprehensive way. Preview of the feature: Instead of actually adding the files, I generate them with a script |
Oh, not to forget: |
This is really interesting @oprypin! So what your "generate" plugin does is execute the given Python scripts that will create the files themselves, using a collector to know how. In your example, the root attribute of the Crystal collector contains the whole tree, so you can walk it. For Python we could do kind of the same, using pytkdocs to walk the tree searching for modules. Since users all have different ways of writing the code reference markdown files, I guess it's best to start with something flexible like this, and maybe later add native methods to the handlers themselves for the most common ways (like one page per module in Python, etc.). Then your plugin inferring the nav is the cherry on top: not only users don't have to write the code reference markdown pages themselves, they don't even have to write the nav either! But if a file is named I'll take a look at your PR in the next few days! |
This makes `handlers_cache` no longer be global but instead be confined to the Plugin. There will be only one instance of the plugin so it doesn't matter anyway. But actually this is also more correct, because what if someone tried to instantiate multiple handlers with different configs? It would work incorrectly previously. But my main goal for this is to expose `MkdocstringsPlugin.get_handler(name)`. Then someone can use this inside a mkdocs hook: def on_files(self, files: Files, config: Config): crystal = config['plugins']['mkdocstrings'].get_handler('python').collector So this is basically a prerequisite for issue #179: one could query the collector to know which files to generate. PR #191: #191
Oho, now I am indeed running into trouble with page names in inferred navigation, and I see what you mean. I'm adding |
I have concluded that the best way forward for Python is to not generate the nav automatically -- only generate the files themselves. And for that, the solution looks like this: Via https://github.com/oprypin/mkdocs-gen-files
(also applied it in #242) |
Could you give more details about that conclusion? Is it too hard to achieve with the current state of our plugins? |
It's not too hard, just more boilerplate than you're getting for it. Reasoning why it's OK to not generate the nav: Reasoning why it's hard to generate the nav: |
I see, thank you for the explanation 🙂 |
See an example in #271 😛 |
I'll close this now. Please take a look at how mkdocstrings generates its own pages and nav, using the mkdocs-gen-files and mkdocs-literate-nav plugins from @oprypin 🙂 |
What's currently the best place to look for docs on this? |
Funny timing, I was exactly going to add a "recipe" for this in a new Recipes page (#378) 🙂 |
mkdocstrings supports the injection as said in docs,
I also have to create the navigation.
This is great because it gives precise control, but is there any existing way to completely generate all the pages with sane defaults?
Like each module's docs in separate page. And links to sub or super module. Something like pdoc3 but using the material theme.
Many thanks for your help
The text was updated successfully, but these errors were encountered: