Add qtbot.waitCallback, take 2

[The-Compiler]

Based on #157, but up-to-date, and with docs and tests and all.

[coveralls]

Coverage increased (+0.02%) to 98.071% when pulling 1b88231 on The-Compiler:wait-callback-2 into 488496d on pytest-dev:master.

[nicoddemus]

A few comments @The-Compiler, truly standing work!

[nicoddemus]

Shouldn't we check if config.getini("qt_wait_signal_raising") returns True or False to raise the warning? Because if users configure it as False, the if block won't execute.

[The-Compiler]

Hmm, I think it's a string (because there's _parse_ini_boolean in qtbot.py), but I wonder why we don't pass type="bool" in the parser.addini calls in pytest_addoption to let pytest do the ini parsing?

[nicoddemus]

No idea... 🤔

[nicoddemus]

But if you see the warning if qt_wait_signal_raising is set to False or True, I'm happy!

[nicoddemus]

Oh also please merge/rebase with master so we get a green build. 👍

[The-Compiler]

This already should make sure the warning is shown with qt_wait_signal_raising = false in the ini as well, as there's a parametrization with configval = "false".

[nicoddemus]

We also should add a new changelog entry.

[The-Compiler]

Rebased (with some trivial fixes squashed) and added a changelog!

[nicoddemus]

Had to push another commit requiring pytest>=3.8... for some reason a few jobs were using an old pytest version. We need 3.7.2 at least because filterwarnings was not a registered mark until then.

[nicoddemus]

Oooh we have a bigger problem then.

UnsatisfiableError: The following specifications were found to be in conflict:
  - pytest[version='>=3.8'] -> atomicwrites[version='>=1.0'] -> python=2.7
  - python=3.4
Use "conda info <package>" to see the dependencies for each package.

That's the reason why it picked a pytest 3.2.3, because it was the last version before we started to depend on atomicwrites, and atomicwrites is not available for Python 3.4.

We need to drop Python 3.4 support or the strict setting from pytest.ini. I think we should go with removing the strict setting as it is a "nice to have" feature instead of dropping a Python version over this. What do you think?

[The-Compiler]

Can't we just register it ourselves in setup.cfg? That's what I did so far when plugins forgot to register their marks, maybe it works for the core as well.

Given that --strict already found a bug in this plugin (2050be8) I'd rather keep it if possible.

[The-Compiler]

FWIW https://pypi.org/project/atomicwrites/ seems to claim supporting 3.4 just fine, and I also don't remember running into any issues - seems like a conda packaging bug or something?

[nicoddemus]

Conda forge does not have that package for 3.4 it seems, only 3.5 onward. Please go ahead with the setup.cfg solution, didn't know it was possible. 👍

[nicoddemus]

Want to do the honors of doing the next release by the way?

[The-Compiler]

Sure, why not! IIRC it was all automated after pushing a tag, right? Probably after #238 though, will also update the changelog there once this is in.

[nicoddemus]

Yep, it is very simple, there's the HOWTORELEASE doc in the repo with the instructions 👍

[The-Compiler]

AppVeyor failed with:

CondaHTTPError: HTTP 500 INTERNAL SERVER ERROR for url 
189<https://conda.anaconda.org/conda-forge/win-64/libpng-1.6.34-vc9_0.tar.bz2>

Doesn't look like I can trigger a rerun myself.

[nicoddemus]

Oh sorry just now saw this.

I've triggered a new build. Unfortunately it seems pytest-qt is under my personal account. But I added you anyway as user, when you have the time see if you have permission to cancel the appveyor build, or trigger a re-build.

[nicoddemus]

Fixed the conflict! 👍

[The-Compiler]

Seems to look good now! :)

[The-Compiler]

Just noticed that I actually fixed another bug here 😆 qtbot.waitSignals() didn't call _parse_ini_boolean like in other places, so raising was "" (so false) when there is no entry for it in the .ini file. This actually ended up hiding a failing test in qutebrowser!