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
Applying plugins: info breaks mkdocs serve
#4883
Comments
I just noticed this is also packaged into the zip file, so every time you (maintainers) use a repro, you have to remove the info plugin rather than just doing |
Thanks for reporting. Yes, the info plugin is still very new, so it might still need some improvement. Only bundling on build is actually a good idea, as it simplifies introspection when using However (and this is a big one), it might lead to the problem where an author has the info plugin still configured, then deploys his docs (which will be built with |
I would say the "annoyance and toil" involved in the current behaviour outweighs the "someone might make a mistake" problem. If someone manages to push the info plugin to CI, they've checked in code to source control without reviewing it and expecting it to work. I think those cases could've pushed it even with the current behaviour and the failure will be the same. |
What is the benefit for the author in implementing the proposed functionality? As a maintainer, yes, there's a benefit, but as an author? It's the last step you exercise in a reproduction. |
I'm not sure about others, but when I author a bug report this is my workflow:
Development is always iterative, just as repro writing, and there's almost always some changes that have to be made to the repro. I collect mine here. From history you can't really see but there's always a In addition to the iterative process, there's sometimes questions about the problem, and the reporter might need to revisit the repro, at this point they're after the last step in the repro process and need to remove the plugin (similar to a maintainer consuming the repro). To take a step a back (might be a silly question), but: |
Thanks for the detailed elaboration. Those are some valid points, and we want to make the bug reporting process as smooth as possible, so I agree that this might help iterating. So, why not support both? In c31ef00, I've added the behavior you requested: plugins:
- info:
enabled_on_serve: true Normally, configuring this should not be necessary, but keeping it configurable doesn't hurt.
Yes. We can't add new commands to MkDocs from within a theme or plugin. Thus, this would have to be added to MkDocs itself. Material for MkDocs is moving faster than MkDocs, which is why this is implemented here. |
Released as part of 9.0.6. |
I can see that from the open issue count :) Thanks for this. |
Yeah, that's exactly what the sponsorships allow: keep the project in good shape and fix bugs quickly. |
Fixed another problem related to this issue in ad6c47d. |
Contribution guidelines
I want to suggest an idea and checked that ...
Description
https://squidfunk.github.io/mkdocs-material/bug-report/reproduction/#creating-a-zip-file says adding the info plugin will make
mkdocs build
create a ZIP. This is fine, but alsomkdocs serve
will do the same. This is unexpected asserve
has a totally different purpose. While I agreeserve
needs tobuild
before serving, the plugin would be much more useful ifmkdocs serve
continues to work as is even when the plugin is applied.Use Cases
When reporting a bug, I would want to be able to see what the built page looks like before zipping it up. When the info plugin is added it's not possible to build any more, which is ok, but not being able to serve either means that I constantly have to add/remove the info plugin if I want to try something additional in the repro.
Screenshots / Mockups
No response
The text was updated successfully, but these errors were encountered: