Since I don't have Python 3.14 on my system (yet), here are the steps I
used to reproduce:
sudo dnf install python3.14
python3.14 -m venv /tmp/py3.14
source /tmp/py3.14/bin/activate
pip install yaml pathspec
python3.14 -m unittest discover
# or
python3.14 -m unittest tests.test_cli.CommandLineTestCase.test_run_default_format_output_in_tty
This commit fixes that by piping *only* `sys.stdout`, not `sys.stderr`
too. I'm not sure why I wrote this code in 2016 (see commit a2c68fdf),
but the new one makes more sense to me now.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2336947
This is a simple preparation for the next commit, to get rid of
low-level `fcntl.fcntl()` calls, since `os.set_blocking()` now exists
(since Python 3.5).
Commit 2344380 "Cleanly skip broken symlinks that are ignored" fixed a
problem on symbolic links but also introduced a change on how ignored
files should be treated, depending on whether they're explicitely passed
as command-line arguments or not [^1].
This change is annoying for users that dynamically build the list of
files to pass as arguments, e.g. [^2]:
find -name '*\.yaml' | xargs yamllint
The present commit adds unit tests for `yamllint [FILES]...` and
`yamllint --list-files [FILES]...`, that passed with previous version
1.34.0, and restore the behavior of this version.
As a result it also reverts the API change of commit 2344380 on
`yamllint.linter.run(stream, config)`.
[^1]: https://github.com/adrienverge/yamllint/issues/657#issuecomment-1948009315
[^2]: https://github.com/adrienverge/yamllint/issues/657#issuecomment-1948093680
Before this commit, yamllint would output "[Errno 2] No such file or
directory" when running on a directory which contained a broken symbolic
link, even if the file is set to be ignored in yamllint configuration.
This commit fixes that, and adds corresponding tests.
As a side effect this changes `yamllint.linter.run(stream, config)`, so
tools that would use this API need to filter ignored files beforehand.
Fixes https://github.com/adrienverge/yamllint/issues/399
Specification of YAML ≤ 1.1 has 22 boolean values:
y | Y | n | N
yes | Yes | YES | no | No | NO
true | True | TRUE | false | False | FALSE
on | On | ON | off | Off | OFF
Whereas YAML 1.2 spec recognizes only 6 [^1]:
true | True | TRUE | false | False | FALSE
For documents that explicit state their YAML spec version at the top of
the document, let's adapt the list of forbidden values.
In the future, we should:
- implement a configuration option to declare the default YAML spec
version, e.g. `default-yaml-spec-version: 1.2`,
- consider making 1.2 the default in a future release (this would be a
slight breaking change, but yamllint always tried to be
1.2-compatible).
- consider adapting yamllint to other 1.1 vs. 1.2 differences [^2].
Solves: https://github.com/adrienverge/yamllint/issues/587
Related to: #559#540#430#344#247#232#158
[^1]: https://yaml.org/spec/1.2.2/#1032-tag-resolution
[^2]: https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21
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
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
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
When {spaces: consistent, indent-sequences: true} (the defaults),
and the expected indent for a block sequence that should be indented
is unknown, set the expected indent to an unknown value (-1) rather
than an arbitrary one (2). This ensures wrong-indentation is properly
caught when block sequences are nested.
Fixes issue #485
The rule correctly reports number values like `.1`, `1e2`, `.NaN` and
`.Inf`, but it also reported false positives on strings like `.1two3`,
`1e2a`, `.NaNa` and `.Infinit∞`.
The regexps need to end with an end delimiter (`$`) otherwise longer
strings can be matched too.
Fixes https://github.com/adrienverge/yamllint/issues/495
Commit c268a82 "key-duplicates: Don't crash on redundant closing
brackets or braces" fixed a problem but introduced another one: it
crashes on systems with (I guess) an old version of PyYAML. This is
probably linked to the "Allow colon in a plain scalar in a flow context"
issue on PyYAML [1].
For example, this problem happens on CentOS 8:
FAIL: test_disabled (tests.rules.test_key_duplicates.KeyDuplicatesTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "…/tests/rules/test_key_duplicates.py", line 90, in test_disabled
'{a:1, b:2}}\n', conf, problem=(2, 11, 'syntax'))
File "…/tests/common.py", line 54, in check
self.assertEqual(real_problems, expected_problems)
AssertionError: Lists differ: …
- [2:3: syntax error: found unexpected ':' (syntax)]
+ [2:11: <no description>]
I propose to simply fix the *space following a colon* problem, since
it's not related to what the original author @tamere-allo-peter tried to
fix.
[1]: https://github.com/yaml/pyyaml/pull/45
- Add a `temp_workspace` context manager to simplify writing new tests.
- Add `# pragma: no cover` to unit test code paths used for skipping tests.
These code paths are only covered when tests are skipped.
That makes it impractical to reach full code coverage on the unit test code.
Having full coverage of unit tests is helpful for identifying unused tests.
- Test the `octal-values` rule with a custom tag.
- Test the cli `-d` option with the `default` config.
- Test support for the `XDG_CONFIG_HOME` env var.
- Test warning message output.
- Test support for `.yamllint.yml` config files.
- Test support for `.yamllint.yaml` config files.
- Test error handling of a rule with a non-enable|disable|dict value.
- Test error handling of `ignore` with a non-pattern value.
- Test error handling of a rule `ignore` with a non-pattern value.
- Test error handling of `locale` with a non-string value.
- Test error handling of `yaml-files` with a non-list value.
- Test extending config containing `ignore`.
- Test `LintProblem.__repr__` without a rule.
- Test `LintProblem.__repr__` with a rule.
The `# -*- coding: utf-8 -*-` headers were useful for Python 2, and
aren't needed for Python 3 where UTF-8 is the default.
yamllint support of Python 2 was dropped in early 2021, see commit
a3fc64d "End support for Python 2".
Let's drop these headers.
Basically, any character is now allowed after the shebang marker.
Closes#428.
Whitespace after the #! marker on shebang lines is authorized and
optional, as explained on Wikipedia's entry for shebang line as can be
seen from the extracts below :
> White space after #! is optional
and
> It has been claimed[20] that some old versions of Unix expect the
> normal shebang to be followed by a space and a slash (#! /), but this
> appears to be untrue;[21] rather, blanks after the shebang have
> traditionally been allowed, and sometimes documented with a space
