Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correctly determine AnyIO support kwargs for run_sync #224

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Stealthii
Copy link

@Stealthii Stealthii commented Sep 19, 2024

#202 introduces an issue on py38 and py39 with an earlier version of importlib.metadata not detecting versions in certain virtual environments. It also uses string comparisons:

Traceback (most recent call last):
  File "example/lib64/python3.8/site-packages/asyncer/__init__.py", line 3, in <module>
    from ._main import PendingValueException as PendingValueException
  File "example/lib64/python3.8/site-packages/asyncer/_main.py", line 17, in <module>
    from asyncer._compat import run_sync
  File "example/lib64/python3.8/site-packages/asyncer/_compat.py", line 16, in <module>
    if ANYIO_VERSION >= "4.1.0":
TypeError: '>=' not supported between instances of 'NoneType' and 'str'

This PR addresses the issue by using inspect to determine anyio's supported kwargs for the run_sync method.

importlib.metadata in Python 3.10 had improved handling of certain
virtual environments. This change addresses the issue with some venv
environments not returning a version string for AnyIO.
@Stealthii
Copy link
Author

Stealthii commented Sep 19, 2024

This bug affects v0.0.8 (the latest version) only.

The PR also contains as prior solution to correctly detect AnyIO package version using importlib-metadata and numeric comparison for Python < 3.10, however this was ultimately replaced with the kwargs check.

We should avoid relying on importlib.metadata outside of build environments as it relies heavily on discoverable dist-info or egg-info metadata, which may not be available in non-virtualenv setups (such as system-level packages).

@Stealthii
Copy link
Author

@tiangolo I would recommend merging and releasing this in the next version before dropping Python 3.8 support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant