- The format() call was missing in the first place for `filename`.
- Other format() calls are obviously useless now that f-strings
perform string interpolation.
Before this change one of yamllint’s tests wasn’t being run on GitHub
Actions Runners because the HOME environment variable couldn’t be
overridden. I just tested it, and it looks like the HOME variable can be
overridden now, so that test no longer needs to be skipped.
Several environment variables can influence which config file yamllint
chooses to use [1]. Before this change, if you set those environment
variables and ran “python -m unittest discover”, then you could cause
certain tests to use the wrong config file and fail.
Fixes#621.
[1]: <152ba20f33/yamllint/cli.py (L180-L188)>
Some unittests set environment variables, but then delete them as part
of their cleanup process. Deleting them is OK. Any test that needs an
environment variable should set that environment variable itself. Once
the test process stops, any changes made to the environment will be lost
[1].
Before this change, there was one location where an environment variable
was restored to its original value instead of deleted. Restoring that
variable was unnecessary.
This commit was created to prepare for a future commit which will delete
HOME before any of the tests even start. Without this change, that
future change would crash. You can’t restore a variable that’s been
deleted.
Fixes#605.
[1]: <https://stackoverflow.com/q/716011/7593853>
Before this change, if certain tests were failing in certain ways, then
running “python -m unittest --buffer” would cause an AttributeError in
the unittest module itself.
Here’s what unittest does when you use the --buffer argument:
1. It sets sys.stdout and sys.stderr to StringIOs [1].
2. It runs a test.
3. If the test failed, it runs getvalue() on sys.stdout and sys.stderr
to get data from its StringIOs.
tests/test_cli.py has its own RunContext class that does something
similar. Before this change, here’s what could happen:
1. unittest sets sys.stdout and sys.stderr to StringIOs.
2. unittest runs a test that uses RunContext.
3. A RunContext gets entered. It sets sys.stdout and sys.stderr to its
own StringIOs.
4. The RunContext gets exited. It sets sys.stdout and sys.stderr to
sys.__stdout__ and sys.__stderr__.
5. The test fails.
6. unittest assumes that sys.stdout is still set to one of its
StringIOs, and runs sys.stdout.getvalue().
7. unittest crashes with this error:
AttributeError: '_io.TextIOWrapper' object has no attribute 'getvalue'
[1]: <2305ca5144/Lib/unittest/result.py (L65)>
[2]: <2305ca5144/Lib/unittest/result.py (L87)>
Flow maps and sequences need quotes if the values contain any of the
flow tokens ({}, [], ','). However, yamllint generates false positives
in these cases:
$ yamllint -d 'rules: {quoted-strings: {required: only-when-needed}}' - <<<'field: ["string[bracket]"]'
1:9 error string value is redundantly quoted with any quotes (quoted-strings)
To fix this, track when inside a flow map/sequence and skip the quoting
checks except for the quoting type.
Closes#516
Existing `anchors` options use quotes around the anchor name:
2:3 error found undeclared alias "unknown" (anchors)
4:3 error found duplicated anchor "dup" (anchors)
Let's do the same in the newly-added option `forbid-unused-anchors`:
5:3 error found unused anchor "not used" (anchors)
According to the YAML specification [^1]:
- > An anchored node need not be referenced by any alias nodes
This means that it's OK to declare anchors but don't have any alias
referencing them. However users could want to avoid this, so a new
option (e.g. `forbid-unused-anchors`) is implemented in this change.
It is disabled by default.
[^1]: https://yaml.org/spec/1.2.2/#692-node-anchors
Because `setup.py` is deprecated, let's switch from:
python setup.py build_sphinx
to:
make -C docs html
to build Sphinx documentation.
The generated HTML files in `docs/_build/html` are exactly the same (I
compared with `diff -qr`).
Also add `-W` (turn warnings into errors) to the `sphinx-build` options
to keep the previous behavior.
In the rare case when the key before `:` is an alias (e.g. `{*x : 4}`),
the space before `:` is required (although this requirement is not
enforced by PyYAML), the reason being that a colon can be part of an
anchor name. Consequently, this commit adapts the `colons` rule to avoid
failures when this happens.
See this comment from Tina Müller for more details:
https://github.com/adrienverge/yamllint/pull/550#discussion_r1155297373
Although accepted by PyYAML, `{*x: 4}` is not valid YAML: it should be
noted `{*x : 4}`. The reason is that a colon can be part of an anchor
name. See this comment from Tina Müller for more details:
https://github.com/adrienverge/yamllint/pull/550#discussion_r1155297373
Even if it's not a problem for yamllint, let's fix our tests to include
valid YAML snippets.
According to the YAML specification [^1]:
- > It is an error for an alias node to use an anchor that does not
> previously occur in the document.
The `forbid-undeclared-aliases` option checks that aliases do have a
matching anchor declared previously in the document. Since this is
required by the YAML spec, this option is enabled by default.
- > The alias refers to the most recent preceding node having the same
> anchor.
This means that having a same anchor repeated in a document is
allowed. However users could want to avoid this, so the new option
`forbid-duplicated-anchors` allows that. It's disabled by default.
- > It is not an error to specify an anchor that is not used by any
> alias node.
This means that it's OK to declare anchors but don't have any alias
referencing them. However users could want to avoid this, so a new
option (e.g. `forbid-unused-anchors`) could be implemented in the
future. See https://github.com/adrienverge/yamllint/pull/537.
Fixes#395Closes#420
[^1]: https://yaml.org/spec/1.2.2/#71-alias-nodes
As reported in https://github.com/adrienverge/yamllint/pull/548, there
might be a problem with pathspec 0.11.1 which does't allow calling
`match_file()` with argument `None` anymore.
The `linter.run()` function shouldn't call
`YamlLintConfig.is_file_ignored(None)` anyway.
rstcheck succeeds with a failure (heh) when there's a code block without
a language specified. This can lead to false negatives as the file is no
longer being checked by rstcheck.
Error:
An `AttributeError` error occured. This is most propably due to a
code block directive (code/code-block/sourcecode) without a
specified language. This may result in a false negative for source:
'docs/disable_with_comments.rst'. See
https://rstcheck-core.readthedocs.io/en/latest/faq/#code-blocks-without-language-sphinx
for more information. Success! No issues detected.
