pytest 6 support

[jonringer]

Using SpecModule constructor directly is deprecated

/nix/store/vyc4y8lwn4ag2jm6xwpdba02ykp4xdw8-python3.7-pytest-relaxed-1.1.5/lib/python3.7/site-packages/pytest_relaxed/plugin.py:31: in pytest_collect_file
    return SpecModule(path, parent)
/nix/store/crb53kmh26fsijj7jpm9pj75j9irajpc-python3.7-pytest-6.0.1/lib/python3.7/site-packages/_pytest/nodes.py:95: in __call__
    warnings.warn(NODE_USE_FROM_PARENT.format(name=self.__name__), stacklevel=2)
E   pytest.PytestDeprecationWarning: Direct construction of SpecModule has been deprecated, please use SpecModule.from_parent.
E   See https://docs.pytest.org/en/stable/deprecations.html#node-construction-changed-to-node-from-parent for more details

[bnavigator]

See #10. But it stopped working with Pytest 6.1

[bnavigator]

Any plans to fix this @bitprophet? All of your projects depending on pytest-relaxed currently fail with pytest 6.

[stanislavlevin]

This has been broken with pytest-dev/pytest@daca174c987389e9cc1a95ce9497dffc6ce51020 There is no more _makeitem method and collect one should be used instead.

[bnavigator]

That's what you get for using private functions

[bitprophet]

To be fair, most of my projects tend to pin their deps in requirements.txt and if they don't, they should! But thanks for bringing this up.

@bnavigator I've been around a while; I would never use a private function if there was an obviously workable public one :( but when one is a client of code that doesn't have the right extension hooks for what you want (not to knock pytest, they put a lot of work into that and pytest-relaxed's use case is a bit of an outlier) sometimes you gotta make do.

I am going around and doing some maintenance upkeep for my projects so I'll try to fit this in somewhere.

[bnavigator]

To be fair, most of my projects tend to pin their deps in requirements.txt and if they don't, they should! But thanks for bringing this up.

Pinning is not an option for rolling distros. Regardless, you are free to do so. These bug reports are merely a hint for you, that your requirements specify old versions, and you need to take action if you want to support newer software. Luckily, only your own projects seem to rely on pytest-relaxed and at openSUSE Tumbleweed we are able to provide pytest5 as alternative for newest pytest (despite you officially only support pytest 4 now!).

@bnavigator I've been around a while; I would never use a private function if there was an obviously workable public one :( but when one is a client of code that doesn't have the right extension hooks for what you want (not to knock pytest, they put a lot of work into that and pytest-relaxed's use case is a bit of an outlier) sometimes you gotta make do.

Sure, as long as you are aware of the fact that it can break any time without notice. (In this case Pytest even mentioned the deprecation of the way you collect items a long time ago: https://docs.pytest.org/en/stable/changelog.html#pytest-3-9-0-2018-10-15-not-published-due-to-a-release-automation-bug)

[hroncok]

Fedora maintainer here. We maintain an alternate old version of pytest just because paramiko and invoke use pytest-relaxed. However this also means we need to fix the old pytest version for new Pythons. If "pin an old pytest version" is the recommended solution, at a certain point it might be easier for us to patch pytest-relaxed out of paramiko (it only uses the raises decorator) and ship invoke untested. I understand the point of view, but I thought I'd share a different one.

[bitprophet]

Thanks @hroncok - that's good context to have (I wish I was more in touch with y'all OS level maintainers).

FWIW my statements earlier shouldn't be construed a "I won't do this" - just explaining why this hasn't been a top priority among my large pile of top priorities (😩 ). I may find time for this as I migrate my projects to newer CI setups and drop Python 2 support, which is next on my plate after some lingering feature releases currently underway.

[hroncok]

Cool, thanks! I'd wish I could help, but there's too much pytest internal magic going on here. I could however test the impact on paramiko/invoke.

[kloczek]

I'm not 100% sure but looks like I've just hit the same bug in my distribtion https://github.com/sqlalchemy/sqlalchemy/issues/6335

[kev009]

FreeBSD ports hit this too (mea culpa) https://cgit.freebsd.org/ports/commit/?id=0c6ce3c9c26d878acf943d53fb2a01ba602b71c2, luckily it's a leaf package with no rev deps.

[bnavigator]

Hello everyone. Just for the record: No pytest 6 support also means no Python 3.10 support. So the only option from here on is @hroncok's proposed approach "patch pytest-relaxed out of paramiko (it only uses the raises decorator) and ship invoke untested". We at openSUSE have already implemented the former a while ago and will soon require to follow with the latter.

[anarcat]

i can't enable the test suite in the debian package because of this as well.

[kuwv]

Python 3.10 requires Pytest 6.2.5 and above: https://github.com/pytest-dev/pytest/pull/8540