[Discussion] about freezing asyncio about freezegun HOT 7 CLOSED

My argument would be that users of freezegun who don't use asyncio should not need to opt-out of asyncio - it is unfortunate that freezegun creates an event loop even when the user does not use or wish to use asyncio. However, there seems to be no reliable way to determine if asyncio is in use, and even the asyncio.get_event_loop and similar functions still open a socket, so hit the same issue.

It appears that pytest-socket has their own asyncio workaround, --allow-unix-socket, so I'll use that for now.

from freezegun.

This also breaks compatibility with pytest-socket. When using freezegun now, even without any use of asyncio, freezegun triggers an asyncio event loop and this in turn tries to use a socket, which pytest-socket blocks, and the test fails:

  File "/usr/local/lib/python3.11/site-packages/_pytest/python.py", line 194, in pytest_pyfunc_call
    result = testfunction(**testargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/freezegun/api.py", line 816, in wrapper
    with self as time_factory:
  File "/usr/local/lib/python3.11/site-packages/freezegun/api.py", line 634, in __enter__
    return self.start()
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/freezegun/api.py", line 739, in start
    event_loop = asyncio.new_event_loop()
                 ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/events.py", line 806, in new_event_loop
    return get_event_loop_policy().new_event_loop()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/events.py", line 695, in new_event_loop
    return self._loop_factory()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/unix_events.py", line 64, in __init__
    super().__init__(selector)
  File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 56, in __init__
    self._make_self_pipe()
  File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 107, in _make_self_pipe
    self._ssock, self._csock = socket.socketpair()
                               ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/socket.py", line 609, in socketpair
    a = socket(family, type, proto, a.detach())
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pytest_socket.py", line 80, in __new__
    raise SocketBlockedError()
pytest_socket.SocketBlockedError: A test tried to use socket.socket.

Since we aren't even using asyncio at all, this is very confusing behaviour. Would it be possible to add a flag or config to freezegun to prevent it from starting asyncio, and thus prevent it from using socket?

from freezegun.

Even when using --allow-unix-socket I'm still seeing issues, freezegun 1.3+ doesn't play nice with pytest-socket on Windows.

Passing tests with freezegun 1.2.2: https://github.com/wimglenn/advent-of-code-data/actions/runs/7123359485/job/19395845855
Failing tests with freezegun 1.3.1: https://github.com/wimglenn/advent-of-code-data/actions/runs/7123099287/job/19395173162

I encountered this in wimglenn/advent-of-code-data#130 - all other pieces held constant, apart from adding the "freezegun < 1.3" constraint. Note: the project under test does not use asyncio at all.

from freezegun.

The 1.3.0 behaviour is now hidden behind a feature-flag, so freezegun should work as normal unless you explicitly enable this.

with freeze_time('1970-01-02', real_asyncio=True):
    ...

This is part of the 1.4.0 release.

from freezegun.

@divad @Mocramis I'd be happy to review a PR with a flag to opt-out. The current behaviour should still be the default though IMO.

from freezegun.

Ah yes, on windows asyncio doesn't use unix sockets / the unix selector, so there is no workaround there as far as I know.

from freezegun.

I think one of the main reason of the original mr was is that freeze_time does not freeze time.sleep while it freezes asyncio.sleep. The original mr forces the original time.monotonic back on the asyncio loop, but it means that the loop time handling will be both inconsistent with time.monotonic and time.time. (also, if the loop had an intentional different time source, it will still replace it by the original time.monotonic)

However, Wouldn't it make sense for a non-ticking freeze_time to also freeze time.sleep ?

from freezegun.