Closed mgorny closed 9 months ago
Hmm, we know that time-machine is only expected to work on cpython, as it uses some internal hooks or something. Is it possible that your version is patched in such a way that it becomes incompatible?
Hmm, we know that time-machine is only expected to work on cpython, as it uses some internal hooks or something. Is it possible that your version is patched in such a way that it becomes incompatible?
No, we're not applying any such patches. Also, time-machine
's tests all pass and I haven't seen any other package crash with it (requests-cache, tox and virtualenv).
Hmm, the traceback appears that it is failing inside time-machine though, so maybe worth opening an issue there?
Sure, I can do that.
Ok, it seems that time-machine
crashes when passing a timedelta
object to travel()
, even though docs suggest that it's a valid use. I'm not going to insist but I was able to work around the problem by using datetime.datetime.now() + ...
instead.
I guess we can wait a few days and see if they fix it in time-machine.
I'm afraid there doesn't seem to be any activity on the time-machine end. Could you apply the workaround, please?
I really do miss the reliable simplicity of freezegun…
Yeah, we looked at time-machine because the last comitter to freezegun said they had given up maintaining freezegun and that time-machine was a better alternative. But, it's starting to look like it has more problems and is just as unmaintained...
Although, actually, there are commits to the beginning of November, maybe they've just taken a long holiday and will be back in January...?
Yeah, let's hope situation improves. That said, there's very little chance for PyPy support, and I really wish time-machine
featured pure Python fallback that would both improve portability and give us an easy way out in case of segfaults.
And, just as time-machine goes silent, freezegun wakes up...
Will see if there's a new release shortly, and then probably revert the commit back to freezegun in that case.
Describe the bug
When running the test suite,
tests/test_cookiejar.py::TestCookieJarSafe::test_max_age
segfaults. I've been able to hit it both with 3.9.0 sdist and with git checkout as of 6f7667336b92dbf09a6a283c2496cdd64ad56a62.It's somehow related to
time-machine
but all its tests pass here, so I suspect aiohttp may be doing something to trigger it.To Reproduce
python3.11 -m venv .venv
make
python -m pytest -s tests/test_cookiejar.py::TestCookieJarSafe::test_max_age
Expected behavior
Tests passing.
Logs/tracebacks
Python Version
aiohttp Version
multidict Version
yarl Version
OS
Gentoo Linux amd64
Related component
Server, Client
Additional context
No response
Code of Conduct