Test warnings in 1.16.0

[yurivict]

============================================================================= warnings summary ==============================================================================
tests/test_cli.py::CommandLineTestCase::test_run_non_existing_file
  /usr/ports/devel/py-yamllint/work-py36/yamllint-1.16.0/tests/test_cli.py:240: DeprecationWarning: Please use assertRegex instead.
    self.assertRegexpMatches(err, r'No such file or directory')

tests/test_cli.py::CommandLineTestCase::test_run_version
  /usr/ports/devel/py-yamllint/work-py36/yamllint-1.16.0/tests/test_cli.py:227: DeprecationWarning: Please use assertRegex instead.
    self.assertRegexpMatches(out + err, r'yamllint \d+\.\d+')

FreeBSD 12 amd64
python-3.6

[adrienverge]

The solution is to transform assertRegexpMatches() to assertRegex() in file tests/test_cli.py, but this new function name is not supported by Python 2.7. For the moment, I'd like to keep support for testing yamllint on Python 2.

[ssbarnea]

@adrienverge That error is really annoying but there is a way to avoid it by disabling this specific warning.

For pytest users there is a nice way to disable these warnings, see an example at https://github.com/ansible-community/molecule/blob/master/setup.cfg#L144-L152 -- in fact it may be possible to do it for other test runners too.

Personally I would not mind dropping support for py27 sooner. A maintenance branch could be created for emergency patches, if the need arises (I had a single case where I had to pin-down one of my dependencies).

[adrienverge]

For pytest users there is a nice way to disable these warnings, see an example at https://github.com/ansible-community/molecule/blob/master/setup.cfg#L144-L152 -- in fact it may be possible to do it for other test runners too.

Interesting, thanks! Do you have a solution that would work for all runners, without adding dependencies?

Personally I would not mind dropping support for py27 sooner. A maintenance branch could be created for emergency patches, if the need arises (I had a single case where I had to pin-down one of my dependencies).

That's smart, but I don't feel these warnings are "really annoying", at least not enough to create and maintain an extra branch. Python 2 support will be dropped at the end of the year.

[ssbarnea]

Python itself allows control of warnings levels using an environment variable, see https://docs.python.org/3/using/cmdline.html#envvar-PYTHONWARNINGS. So you could make it generic as long you define this environment variable.

AFAIK, this variable must be loaded before the interpreter starts, so is likely that it will not work to hack it inside your setup.py. For setup.py you could use warnings api directly to configure them but I am afraid that anything involving changes to setup.py is discourages as its future is clear: setup.py is to be removed, mainly due to security issues. Even if implemented it will have zero effect for anything else nose/pytest/stestr/..., which do not call setup.py

I think that the "all runners" goal is a bit too broad, is like saying that one project would want to support "any python" version, sooner or later one needs to make some trade-offs.

For example, you could create a Makefile with a make test target that runs PYTHONWARNINGS=... python setup.py test. The funny part is that this would be just another "runner". Documenting it would not make it easy to ignore the warning, as it would make calling the test much harder.

PS. pypa/setuptools#1684 may also be of interest for you.

[adrienverge]

Python 2 support has been dropped and these test warnings do not appear anymore.