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
