rule new-lines: add type: platform configuration option

[Cube707]

This PR follows up on #456 in which it was concluded that the default for the new-lines rule should not be changed but rather a new option is to be introduced.

Problem

As explained in this comment on the parent PR yamllint currently has portability issues that make it hard to use on Windows clients. These stem from git converting line-endings to the platform default on checkout and yamllint assuming that the line-ending type should be enforced for all development platforms. This leads to windows-clients needing to be heavily reconfigured to make yamllint work there properly.

PR's content

This PR introduces a new option for the new-lines rule: type: auto.

The new option infers the correct newline character(s) from the operating system that is currently running yamllint. This allows developers to create yaml-files with their systems default settings and relying on git to convert them.

Projects that wish to enforce a certain type of line-ending are still able to do so by keeping one of the original two options.

Linting / Testing

flake8, doc8 and unittest completet without error on my local machine.

[coveralls]

Coverage increased (+0.003%) to 99.15% when pulling 1d958a9 on Cube707:platform-newlines into 695fc5f on adrienverge:master.

[adrienverge]

@Cube707 thanks for this PR!

I still think type: platform is better than type: auto, because auto relates to auto-detection from the file in other parts of yamllint. On the other hand, platform causes no ambiguity.

Please see the lint results, there are some errors.

You can remove rule from the commit title: rule new-lines: ..., for consistency with other commits.

About the first commit explicitly check \n for type: unix, I don't understand it, and I'm not sure what kind of side-effects it could have. Please check out bullet 6 of the contributing guidelines: anyone should be able to quickly read and understand the reason for a change (in case it induces problems on some platforms, for example...)

[Cube707]

Is the commit history so acceptable? Or should I still remove the explicitly check \n for type: unix commit? (or explain it better?)

Are you OK with having the refactoring as a separate commit? I expect this would make it easier to find the source of problems between the new option and the refactoring. But I can also make it a single commit.

Thanks for spending so much time on this!

EDIT: I will also rebase after the comments below are resolved.

[adrienverge]

Thanks @Cube707!

The history looks good but I would prefer:
- either merging the 2 last commits (refactor + add 'platform'),
- or applying the refactor before the 'platform' addition,
in order to reduce the diff and the hassle of git blame.

[Cube707]

should be good now.

unittest and flake8 pass on my machine.

[adrienverge]

Looks good to me, but the linter complains: you need to add an extra line before the new import from os import linesep.

yamllint/rules/new_lines.py:docstring of yamllint.rules.new_lines:9:Bullet list ends without a blank line; unexpected unindent.

[Cube707]

found the problem. There was a \n in the docstring that was not properly escaped. (See compare)

python setup.py build_sphinx complets now on my machine.

[Cube707]

rebased onto master

[adrienverge]

found the problem. There was a \n in the docstring that was not properly escaped. (See compare)

Well seen.

[adrienverge]

Thanks for this work Jan! 👍