I'm afraid I'm going to have to cry uncle on this one. I am no expert at all on async stuff, and cached_property is actually doing something kind of unusual with it which the release notes do not cover. It looks like it was all written before PEP 492 was a thing, and never updated. Its async test code uses this wrapper:

def unittest_run_loop(f):
    def wrapper(*args, **kwargs):
        coro = asyncio.coroutine(f)
        future = coro(*args, **kwargs)
        loop = asyncio.get_event_loop()
        loop.run_until_complete(future)

    return wrapper

which calls `asyncio.coroutine` *directly*. Then various tests (which are themselves decorated as `asyncio.coroutine`) have that wrapper applied to them. I sort of see the intent, I think - it means "just run this whole asynchronous test function until everything is exhausted" - but I don't really see how you'd translate that to the modern 'async def' syntax. Can anyone who's better at this stuff help?

I tried a couple of things - replacing the wrapper with just a call to `await(f(*args, **kwargs))`, and replacing the wrapper entirely with use of `@pytest.mark.asyncio` from pytest-asyncio - but those don't seem to work properly. With them, the tests pass, but I get warnings indicating the tests were never really run:

tests/test_async_cached_property.py::TestCachedProperty::test_cached_property
tests/test_coroutine_cached_property.py::TestCachedProperty::test_cached_property
  /usr/lib64/python3.10/unittest/case.py:549: RuntimeWarning: coroutine 'TestCachedProperty.test_cached_property' was never awaited
    method()

...and indeed, if I hack up a test such that it should fail (assert a wrong value), it doesn't.

Upstream on this project is very unresponsive lately, so I'm not sure I'll get anywhere filing an issue there, but I'll do it.

I've sent a PR upstream, you might want to take the patch: https://github.com/pydanny/cached-property/pull/267
With this, adding errors to the functions makes the tests fail.

cached_property is also available in the Python 3.8+ standard library (without asyncio integration though): https://docs.python.org/3/library/functools.html#functools.cached_property
It might be good to help projects that need cached_property start migrating to that.

Thanks, on both counts! I look after python-cached_property primarily because my own thing (fedfind) uses it. I can look at migrating to the functools one (I don't use asyncio stuff); the only issue may be maintaining support for EPEL 8, I'll have to look into that.

OK, successful Rawhide build with Petr's patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=79522426 . Closing.

> the only issue may be maintaining support for EPEL 8, I'll have to look into that.

usually done with something like:

try:
    from functools import cached_property
except ImportError:
    # Python 3.7 and lower
    from cached_property import cached_property

and for conditional dependencies in Python metadata, see e.g. https://github.com/PyCQA/astroid/blob/6691a9e97373b28e15a76b747f78c041f2064df4/setup.cfg#L43

that's what I'm trying to avoid, because I hate having to maintain that kinda stuff :( and I don't know if the Fedora macros that handle tox dependencies know about / correctly handle that syntax (probably not, so I'd have to have conditionals in the spec file or fork it, and that again is the kinda stuff I don't want to deal with...)

What I'm saying is it'd be much easier if we could just package for Python 3.8 on EL 8, hint hint :P

> I don't know if the Fedora macros that handle tox dependencies know about / correctly handle that syntax

They do.

oh, that would help. Thanks.

unfortunately, looks like the pyproject-rpm-macros stuff doesn't exist in EPEL 8, and probably can't as EL 8's rpm is too old. So I can make the spec very shiny and simple for Fedora, but not for EPEL branches.

Indeed, that is the case.

However, at least the runtime dependency generator should work on EPEL 8.