Currently importing yamllint recursively imports its submodules, which
finally requires having pyyaml installed. This is a problem when you
just want to import APP_VERSION from yamllint. For instance, setup.py
imports yamllint to know the version, but doesn't know yet that pyyaml
is to be installed, because it is stated in setup.py itself.
To solve this, yamllint/__init__.py will only contain constants. The
linting functions will be in yamllint/linter.py.
The `pyyaml` dependency is needed in `install_requires` but also in
`setup_requires`, because running `setup.py` requires importing
`yamllint`, which itself imports `yaml`.
HTML documentation should be built with sphinx. This enables easy
integration with Read The Docs [1]. It can also be generated manually by
running:
make -C docs html
A man page can be generated by running:
make -C docs man
[1]: http://yamllint.readthedocs.org/
This options allows the user to control whether to lint indentation
inside multi-line scalars or not.
When enabled, such YAML source will be detected as a problem:
- C code: void main() {
printf("foo");
}
whereas this one would not:
- C code: void main() {
printf("foo");
}
YAML content like the following one produced an error, because the
multi-line ScalarToken ends at the beginning of the 4th line (the one
with the value):
? >
multi-line
key
: value
YAML content like the following one produced an error, because the
ScalarToken associated whose value is "this is plain text" ends at the
beginning of the 5th line (the one with the comment):
---
string: >
this is plain text
# comment
Using either 'yes', 'no' or 'whatever', the user will be able to choose
whether to force block sequence items to be indented, to force them not
to be indented, or don't care, respectively.
Previously only comments that were indented like the following content
line were allowed, e.g.:
prev: line:
# commented line
current: line
With this change, such new cases are also allowed:
prev: line
# commented line 1
# commented line 2
current: line
When both a syntax error (unability to parse a document) and a cosmetic
yamllint problem are found at the same place, the yamllint problem had
the priority -- and the syntax error was not displayed.
This had the following problem: if a rule is at the 'warning' level, its
problems will not make the `yamllint` script return a failure return
code (`!= 0`), even when it should (because there was a syntax error,
precisely).
This commit changes this behavior by preferring yamllint problems only
when they have the 'error' level.
`yaml.load()` exceptions are not necessarily syntax errors. For
instance, the following YAML source cannot be `load()`ed into a Python
object, but is valid nonetheless:
? - Detroit Tigers
- Chicago cubs
:
- 2001-07-23
? [ New York Yankees,
Atlanta Braves ]
: [ 2001-07-02, 2001-08-12,
2001-08-14 ]
This commit detects syntax errors from `yaml.parse()` exceptions rather
than `yaml.load_all()`.
