search

timvink / mkdocs-git-revision-date-localized-plugin

MkDocs plugin to add a last updated date to your site pages
https://timvink.github.io/mkdocs-git-revision-date-localized-plugin/index.html
MIT License
198 stars 40 forks source link

Remove Unable to find a git directory and/or git is not installed warning on local only builds #58

Closed aphive closed 3 years ago

aphive commented 3 years ago

When working on a local only docs site, is there a way to not let this warning show up? When you get to having many pages it becomes a useless nuisance as we already know there is no git configuration set.

timvink commented 3 years ago

Hi @aphive.

So you have a local docs folder that is not under version control (not a git repo). Because you're getting a warning instead of an error, that means you have fallback_to_build_date enabled in your mkdocs.yml

https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/e0d80ac727cbe1533e92eda4700cb6faf677e345/mkdocs_git_revision_date_localized_plugin/util.py#L121-L127

I am wondering what your use case is, and what the best solution then would be. I see two:

1) You're developing locally but intend to publish to an environment with git later. This plugin could have a new option to disable itself using an environment variable (for which mkdocs 1.2 adds really nice support https://www.mkdocs.org/user-guide/configuration/#environment-variables), so it will only be disabled when you have a specific env var setup.

2) The actual behaviour you want is not the revision date but the last build date (last time mkdocs serve or mkdocs build was run). You want that behaviour without the warnings. In that case, a new option suppress_warnings would be probably be the most elegant solution to accomodate your use case.

Also wondering if commenting out the plugin in your mkdocs.yml while developing locally would be an option?

Let me know what you think!

aphive commented 3 years ago

Thanks for the feedback. I think having both option 1 and 2 option to suppress_warnings would be the right way to go. Option one would serve best for cases where builds do take advantage of the env variable and option two would serve for cases where no other env will be used.

For the time being, I can work with the plugin disabled. Wondering tho if there could potential missed issues due to no warning showing.

timvink commented 3 years ago

I've added a new enabled option in v.0.10.0, that you can use with environment variables (see docs). Because you can use fallbacks, I think that should be sufficient. I agree that adding suppress_warnings could cause missing potentially missed issues --> probably not a good design choice.