nolte / ansible-role-mcrcon

Ansible Role for install Minecraft Rcon tool.
https://nolte.github.io/ansible-role-mcrcon
0 stars 1 forks source link

Update dependency mkdocs to v1.5.2 #76

Closed renovate[bot] closed 10 months ago

renovate[bot] commented 11 months ago

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
mkdocs (changelog) ==1.2.3 -> ==1.5.2 age adoption passing confidence

Release Notes

mkdocs/mkdocs (mkdocs) ### [`v1.5.2`](https://togithub.com/mkdocs/mkdocs/releases/tag/1.5.2) [Compare Source](https://togithub.com/mkdocs/mkdocs/compare/1.5.1...1.5.2) - Bugfix (regression in 1.5.0): Restore functionality of `--no-livereload`. ([#​3320](https://togithub.com/mkdocs/mkdocs/issues/3320)) - Bugfix (regression in 1.5.0): The new page title detection would sometimes be unable to drop anchorlinks - fix that. ([#​3325](https://togithub.com/mkdocs/mkdocs/issues/3325)) - Partly bring back pre-1.5 API: `extra_javascript` items will once again be mostly strings, and only sometimes `ExtraStringValue` (when the extra `script` functionality is used). Plugins should be free to append strings to `config.extra_javascript`, but when reading the values, they must still make sure to read it as `str(value)` in case it is an `ExtraScriptValue` item. For querying the attributes such as `.type` you need to check `isinstance` first. Static type checking will guide you in that. ([#​3324](https://togithub.com/mkdocs/mkdocs/issues/3324)) See [commit log](https://togithub.com/mkdocs/mkdocs/compare/1.5.1...1.5.2). ### [`v1.5.1`](https://togithub.com/mkdocs/mkdocs/releases/tag/1.5.1) [Compare Source](https://togithub.com/mkdocs/mkdocs/compare/1.5.0...1.5.1) - Bugfix (regression in 1.5.0): Make it possible to treat `ExtraScriptValue` as a path. This lets some plugins still work despite the breaking change. - Bugfix (regression in 1.5.0): Prevent errors for special setups that have 3 conflicting files, such as `index.html`, `index.md` *and* `README.md` ([#​3314](https://togithub.com/mkdocs/mkdocs/issues/3314)) See [commit log](https://togithub.com/mkdocs/mkdocs/compare/1.5.0...1.5.1). ### [`v1.5.0`](https://togithub.com/mkdocs/mkdocs/releases/tag/1.5.0) [Compare Source](https://togithub.com/mkdocs/mkdocs/compare/1.4.3...1.5.0) **New: MkDocs now accepts donations.** Please consider supporting the current maintainer at my new GitHub sponsorship page. MkDocs has been a totally free project since the beginning and wasn't accepting funds. MkDocs will remain free of paywalls, but now you can show your support with donations (one-time and/or recurring). [**Donate for MkDocs - @​oprypin sponsors page**](https://togithub.com/sponsors/oprypin) And please also consider these other individuals who have been contributing to the ecosystem for a long time and check out their donations pages: [@​facelessuser](https://togithub.com/sponsors/facelessuser) [@​pawamoy](https://togithub.com/sponsors/pawamoy) [@​Ultrabug](https://togithub.com/sponsors/Ultrabug) *** ##### Release 1.5.0 #### New command `mkdocs get-deps` This command guesses the Python dependencies that a MkDocs site requires in order to build. It simply prints the PyPI packages that need to be installed. In the terminal it can be combined directly with an installation command as follows: ```bash pip install $(mkdocs get-deps) ``` The idea is that right after running this command, you can directly follow it up with `mkdocs build` and it will almost always "just work", without needing to think which dependencies to install. The way it works is by scanning `mkdocs.yml` for `themes:`, `plugins:`, `markdown_extensions:` items and doing a reverse lookup based on a large list of known projects (catalog, see below). Of course, you're welcome to use a "virtualenv" with such a command. Also note that for environments that require stability (for example CI) directly installing deps in this way is not a very reliable approach as it precludes dependency pinning. The command allows overriding which config file is used (instead of `mkdocs.yml` in the current directory) as well as which catalog of projects is used (instead of downloading it from the default location). See [`mkdocs get-deps --help`](https://www.mkdocs.org/user-guide/cli/#mkdocs-get-deps). Context: [#​3205](https://togithub.com/mkdocs/mkdocs/issues/3205) #### MkDocs has an official catalog of plugins Check out and add all your general-purpose plugins, themes and extensions there, so that they can be looked up through `mkdocs get-deps`. This was renamed from "best-of-mkdocs" and received significant updates. In addition to `pip` installation commands, the page now shows the config boilerplate needed to add a plugin. #### Expanded validation of links ##### Validated links in Markdown > As you may know, within Markdown, MkDocs really only recognizes **relative** links that lead to another physical `*.md` document (or media file). This is a good convention to follow because then the source pages are also freely browsable without MkDocs, for example on GitHub. MkDocs knows that in the output it should turn those `*.md` links into `*.html` as appropriate, and it would also always tell you if such a link doesn't actually lead to an existing file. However, the checks for links were really loose and had many concessions. For example, links that started with `/` ("absolute") and links that *ended* with `/` were left as is and no warning was shown, which allowed such very fragile links to sneak into site sources: links that happen to work right now but get no validation and links that confusingly need an extra level of `..` with `use_directory_urls` enabled. Now, in addition to validating relative links, MkDocs will print `INFO` messages for unrecognized types of links (including absolute links). They look like this: ```text INFO - Doc file 'example.md' contains an absolute link '/foo/bar/', it was left as is. Did you mean 'foo/bar.md'? ``` If you don't want any changes, not even the `INFO` messages, and wish to revert to the silence from MkDocs 1.4, add the following configs to `mkdocs.yml` (**not** recommended): ```yaml validation: absolute_links: ignore unrecognized_links: ignore ``` If, on the opposite end, you want these to print `WARNING` messages and cause `mkdocs build --strict` to fail, you are recommended to configure these to `warn` instead. See [**documentation**](https://www.mkdocs.org/user-guide/configuration/#validation) for actual recommended settings and more details. Context: [#​3283](https://togithub.com/mkdocs/mkdocs/issues/3283) ##### Validated links in the nav Links to documents in the [`nav` configuration](https://www.mkdocs.org/user-guide/configuration/#nav) now also have configurable validation, though with no changes to the defaults. You are welcomed to turn on validation for files that were forgotten and excluded from the nav. Example: ```yaml validation: nav: omitted_files: warn absolute_links: warn ``` This can make the following message appear with the `WARNING` level (as opposed to `INFO` as the only option previously), thus being caught by `mkdocs --strict`: ```text INFO - The following pages exist in the docs directory, but are not included in the "nav" configuration: ... ``` See [**documentation**](https://www.mkdocs.org/user-guide/configuration/#validation). Context: [#​3283](https://togithub.com/mkdocs/mkdocs/issues/3283), [#​1755](https://togithub.com/mkdocs/mkdocs/issues/1755) ##### Mark docs as intentionally "not in nav" There is a new config `not_in_nav`. With it, you can mark particular patterns of files as exempt from the above `omitted_files` warning type; no messages will be printed for them anymore. (As a corollary, setting this config to `*` is the same as ignoring `omitted_files` altogether.) This is useful if you generally like these warnings about files that were forgotten from the nav, but still have some pages that you knowingly excluded from the nav and just want to build and copy them. The `not_in_nav` config is a set of gitignore-like patterns. See the next section for an explanation of another such config. See [**documentation**](https://www.mkdocs.org/user-guide/configuration/#not_in_nav). Context: [#​3224](https://togithub.com/mkdocs/mkdocs/issues/3224), [#​1888](https://togithub.com/mkdocs/mkdocs/issues/1888) #### Excluded doc files There is a new config `exclude_docs` that tells MkDocs to ignore certain files under `docs_dir` and *not* copy them to the built `site` as part of the build. Historically MkDocs would always ignore file names starting with a dot, and that's all. Now this is all configurable: you can un-ignore these and/or ignore more patterns of files. The `exclude_docs` config follows the [.gitignore pattern format](https://git-scm.com/docs/gitignore#\_pattern_format) and is specified as a multiline YAML string. For example: ```yaml exclude_docs: | *.py # Excludes e.g. docs/hooks/foo.py /drafts # Excludes e.g. docs/drafts/hello.md /requirements.txt # Excludes docs/requirements.txt ``` Validation of links (described above) is also affected by `exclude_docs`. During `mkdocs serve` the messages explain the interaction, whereas during `mkdocs build` excluded files are as good as nonexistent. As an additional related change, if you have a need to have both `README.md` and `index.md` files in a directory but publish only one of them, you can now use this feature to explicitly ignore one of them and avoid warnings. See [**documentation**](https://www.mkdocs.org/user-guide/configuration/#exclude_docs). Context: [#​3224](https://togithub.com/mkdocs/mkdocs/issues/3224) ##### Drafts The `exclude_docs` config has another behavior: all excluded Markdown pages will still be previewable in `mkdocs serve` only, just with a "DRAFT" marker on top. Then they will of course be excluded from `mkdocs build` or `gh-deploy`. If you don't want `mkdocs serve` to have any special behaviors and instead want it to perform completely normal builds, use the new flag `mkdocs serve --clean`. See [**documentation**](https://www.mkdocs.org/user-guide/configuration/#exclude_docs). Context: [#​3224](https://togithub.com/mkdocs/mkdocs/issues/3224) #### `mkdocs serve` no longer exits after build errors If there was an error (from the config or a plugin) during a site re-build, `mkdocs serve` used to exit after printing a stack trace. Now it will simply freeze the server until the author edits the files to fix the problem, and then will keep reloading. But errors on the *first* build still cause `mkdocs serve` to exit, as before. Context: [#​3255](https://togithub.com/mkdocs/mkdocs/issues/3255) #### Page titles will be deduced from any style of heading MkDocs always had the ability to infer the title of a page (if it's not specified in the `nav`) based on the first line of the document, if it had a `

` heading that had to written starting with the exact character `#`. Now any style of Markdown heading is understood ([#​1886](https://togithub.com/mkdocs/mkdocs/issues/1886)). Due to the previous simplistic parsing, it was also impossible to use `attr_list` attributes in that first heading ([#​3136](https://togithub.com/mkdocs/mkdocs/issues/3136)). Now that is also fixed. #### Markdown extensions can use paths relative to the current document This is aimed at extensions such as `pymdownx.snippets` or `markdown_include.include`: you can now specify their include paths to be relative to the currently rendered Markdown document, or relative to the `docs_dir`. Any other extension can of course also make use of the new `!relative` YAML tag. ```yaml markdown_extensions: - pymdownx.snippets: base_path: !relative ``` See [**documentation**](https://www.mkdocs.org/user-guide/configuration/#paths-relative-to-the-current-file-or-site). Context: [#​2154](https://togithub.com/mkdocs/mkdocs/issues/2154), [#​3258](https://togithub.com/mkdocs/mkdocs/issues/3258) #### ` Githubissues.
  • Githubissues is a development platform for aggregating issues.