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.
Recently `python setup.py build_sphinx` started failing with:
pkg_resources.VersionConflict: (Pygments 2.3.1
(/usr/lib/python3/dist-packages), Requirement.parse('Pygments>=2.12'))
The reason is that `doc8` 1.0.0 installs `Pygments` 2.3.1, then `Sphinx`
5.3.0 needs `Pygments` ≥ 2.12.
The easiest fix is to change the install order.
This problem was just introduced by commit cec4f33 "Clarify disable-line
and parser errors, workaround" and produced this error when building
documentation:
docs/disable_with_comments.rst:120:Could not lex literal_block as
"yaml". Highlighting skipped.
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
This reverts commit 3c525ab "Release as a universal wheel".
Python 2 support was definitely dropped in early 2021 in commit a3fc64d,
since then it's no longer useful to build universal wheels.
According to the `wheel` documentation:
> If your project contains no C extensions and is expected to work on
> both Python 2 and 3, you will want to tell wheel to produce universal
> wheels
Partly fixes https://github.com/adrienverge/yamllint/issues/501
It is unnecessary to use an `if` statement to check the maximum of two
values and then assign the value to a name. You can use the max
built-in do do this. It is straightforward and more readable.
To check if a variable is equal to one of many values, combine the
values into a tuple and check if the variable is contained in it
instead of checking for equality against each of the values. This
is faster, less verbose, and more readable.
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
From the Python 3 documentation:
Match objects always have a boolean value of True.
Since match() and search() return None when there is no match,
you can test whether there was a match with a simple if statement:
match = re.search(pattern, string)
if match:
process(match)
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
To be consistent with other existing messages, e.g.:
- forbidden not a number value ".NaN"
- found forbidden document start "---"
- missing document start "---"
- truthy value should be one of ["true"]
- forbidden implicit octal value "0777"
Both options where using identical code. Now the newline character
is determined beforehand depending on the selected option and then
the same code can be used for all options
To be more consistent with the other types, unix now also checks against
the expected newline character (`\n`) instead of checking if a wrong
character (`\r`) is present
Remove the redundant conditional used when reporting a syntax error
at the same location as a cosmetic problem. Also reword the comment
explaining the logic to more accurately describe the situation.
This eliminates an unreachable `syntax_error = None` assignment.
Remove two `try/except UnicodeError` exception handlers which were
added in commit c8ba8f7e99 for
Python 2.x compatibility. Now that Python 2.x is no longer
supported, the `except` is unreachable and is no longer needed.
- 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.
Set the 'description' attribute so that Sphinx builds the manpage with
the 'NAME' section. This is necessary for `apropos` to be able to find
yamllint
Fixes part of #76
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
This reverts commit 8f68248 "Remove runtime dep 'setuptools' for Python
< 3.8". It looks like removing setuptools induces problems on some
systems, see for example the linked discussion.
Fixes https://github.com/adrienverge/yamllint/issues/380.
PyYAML implements YAML spec version 1.1, not 1.2. Hence, values starting
with `0o` are not considered as numbers: they are just strings, so they
need quotes when `quoted-strings: {required: true}`.
>>> import yaml
>>> yaml.resolver.Resolver().resolve(yaml.nodes.ScalarNode, '100', (True, False))
'tag:yaml.org,2002:int'
>>> yaml.resolver.Resolver().resolve(yaml.nodes.ScalarNode, '0100', (True, False))
'tag:yaml.org,2002:int'
>>> yaml.resolver.Resolver().resolve(yaml.nodes.ScalarNode, '0o100', (True, False))
'tag:yaml.org,2002:str'
Let's try to prevent that.
Fixes https://github.com/adrienverge/yamllint/issues/351.
We'd like to disallow brackets and braces in our YAML, but there's a
catch: the only way to describe an empty array or hash in YAML is to
supply an empty one (`[]` or `{}`). Otherwise, the value will be null.
This commit adds a `non-empty` option to `forbid` for brackets and
braces. When it is set, all flow and sequence mappings will cause errors
_except_ for empty ones.
Using `python setup.py test` is now deprecated [1], users are encouraged
to be explicit about the test command.
Running yamllint tests using the Python standard library (`unittest`)
can be done using:
python -m unittest discover
Why not nose, tox or pytest? Because they would add a dependency, make
tests running more complicated and verbose for new users, and their
benefit is not worth for this simple project (only 2 runtime
dependencies: PyYAML and pathspec).
Resolves https://github.com/adrienverge/yamllint/issues/328.
[1]: https://github.com/pypa/setuptools/pull/1878
Quick PR to ignore the `/.eggs` folder, which appears to be generated every
time the `python setup.py test` command is run.
The content of the `./.eggs/README.txt` file:
> This directory contains eggs that were downloaded by setuptools to build,
> test, and run plug-ins.
>
> This directory caches those eggs to prevent repeated downloads.
>
> However, it is safe to delete this directory.
Fixes#325
The linter allows a directive to contain trailing whitespace characters like
\r, but does not trim them before iterating on the rules. As a result, the last
rule in the list contains the trailing whitespace characters and never matches
any existing rule.
I added the necessary trimming, as well as a test with 2 checks to go along
with it.
yamllint depends on pkg_resources.load_entry_point from setuptools to
make its command working, so this runtime dependency to setuptools is
necessary to be listed.
Add 'forbid' configuration parameters to the braces and brackets rules
to allow users to forbid the use of flow style collections, flow
mappings and flow sequences.
Move setuptools' packaging configuration from setup.py to setup.cfg to
simplify setup.py and make its packaging more dedeclarative.
Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com>
Pound-signs followed by a lone CRLF should not
raise if require-starting-space is specified.
If require-starting-space is true, *and* either:
- new-lines: disbale, or
- newlines: type: dos
is specified, a line with `#\r` or `#\r\n` should
not raise a false positive.
This commit also uses a Set for O(1) membership testing
and uses the correct escape sequence for the nul byte.
If we find a CRLF when looking for Unix newlines, yamllint
should always raise, regardless of logic with
require-starting-space.
Closes: Issue #171.
Add ability to:
- require strings to be quoted if they match a pattern (PCRE regex)
- allow quoted strings if they match a pattern, while `require:
only-when-needed` is enforced.
Co-Authored-By: Leo Feyer (https://github.com/adrienverge/yamllint/pull/246)
The rule worked for values like:
flow-map: {a: foo, b: "bar"}
block-map:
a: foo
b: "bar"
But not for:
flow-seq: [foo, "bar"]
block-seq:
- foo
- "bar"
Also add tests to make sure there will be no regression.
Fixes: #208.
Use io.open() when reading files in cli which has the same behaviour
in Python 2 and Python 3, and supply the newline='' parameter which
handles but does not translate line endings.
Add dos.yml test file with windows newlines.
Also add to file finding test expected output.
Add test for new-lines rule through the cli.
Validates files are read with the correct universal newlines setting.
Fixesadrienverge/yamllint#228
Single context manager that includes exit code and output streams.
Use new RunContext throughout test_cli.
Largely non-functional change, saving some repetition of setup.
Also improve some failures by bundling multiple assertions into one.
Make sure values passed in allowed values are correct ones. This is
possible thanks to previous commit, and should prevent users from
writing incorrect configurations.
Allow rules to declare a list of valid values for an option.
For example, a rule like:
CONF = {'allowed-values': list}
... allowed any value to be passed in the list (including bad ones).
It is now possible to declare:
CONF = {'allowed-values': ['value1', 'value2', 'value3']}
... so that the list passed to the options must contain only values in
`['value1', 'value2', 'value3']`.
Edit documentation for the `truthy` rule, in order to:
- add quotes to examples (`'yes'` instead of `yes`) to avoid
misconfigurations,
- group truthy values in the `allowed-values` option paragraph, for
easier reading.
Allows using key `allowed-values` for `truthy` section in configuration file (#150).
This allows to use configuration `truthy: allowed-values: ["yes", "no",
"..."]`, to set custom allowed truthy values.
This is especially useful for people using ansible, where values like
`yes` or `no` are valid and officially supported, but yamllint reports
them as illegal.
Implemented by difference of set of TRUTHY constants and configured
allowed values.
Signed-off-by: Ondrej Vasko <ondrej.vaskoo@gmail.com>
Some usages of YAML (like Ansible) supports running the file as a script.
Support (by default) an ignore-shebangs setting for the comments module.
Fixes#116 - comments rule with require-starting-space: true should special case shebang
Before, it was required to specify all the options when customizing a
rule. For instance, one could use `empty-lines: enable` or `empty-lines:
{max: 1, max-start: 2, max-end: 2}`, but not just `empty-lines: {max:
1}` (it would fail with *invalid config: missing option "max-start" for
rule "empty-lines"*).
This was a minor problem for users, but it prevented the addition of new
options to existing rules, see [1] for an example. If a new option was
added, updating yamllint for all users that customize the rule would
produce a crash (*invalid config: missing option ...*).
To avoid that, let's embed default values inside the rules themselves,
instead of keeping them in `conf/default.yaml`.
This refactor should not have any impact on existing projects. I've
manually checked that it did not change the output of tests, on
different projects:
- ansible/ansible: `test/runner/ansible-test sanity --python 3.7 --test yamllint`
- ansible/molecule: `yamllint -s test/ molecule/`
- Neo23x0/sigma: `make test-yaml`
- markstory/lint-review: `yamllint .`
[1]: https://github.com/adrienverge/yamllint/pull/151
The `pkg_resources` package inside `setuptools` explicitly [disallows
Python 3.3](7392f01ffc (diff-81de4a30a55fcc3fb944f8387ea9ec94)):
if (3, 0) < sys.version_info < (3, 4):
raise RuntimeError("Python 3.4 or later is required")
It's time to drop support for 3.3.
`-f standard` shows non-colored output,
`-f colored` shows colored output,
`-f auto` is the new default, it chooses `standard` or `colored`
depending on terminal capabilities.