Add the asyncio_default_fixture_loop_scope option.

[stankudrow]

Closes #136 .
Closes #195 .

Requires to bump the pytest-asyncio to the v 1.0.0 (released 2025-03-26), works fine with the Py3.9.

[Tinche]

LGTM, but can we use the function scope instead? It's a little slower but no sharing probably makes for more isolated tests.

BTW if you're looking for stuff to contribute, there are two larger projects: start testing on 3.14 (which has entered beta) and porting to uv.

[stankudrow]

LGTM, but can we use the function scope instead? It's a little slower but no sharing probably makes for more isolated tests.

BTW if you're looking for stuff to contribute, there are two larger projects: start testing on 3.14 (which has entered beta) and porting to uv.

Sure, will narrow down the scope to the "function". UPD: done. Are you happy with the pytest-asyncio bumped to the v1.0.0? Or would you prefer an older version of this plugin?

Yeah, I'd love to contribute.

1. Porting to uv seems promising and doable, I'll make a try.
2. Is it OK to adopt a beta version? I though that stable versions are good to support.
3. I also would like to finish the PR Add the to_coro function with the asyncio.to_thread underneath -> deprecating the wrap function. #213 in order to unlock the Add os.walk wrapper #193 and introduce generator asynchronising tools with the os.walk as an example, so I need your review and help with these PRs. These PRs may (I guess definitively) require a new v25.0 release (if I am correct with understanding semver rules), but, if we can find a proper and cheaper solution in the Add os.walk wrapper #193, this may pave a way towards async wrappers over sync generators which is an enhancing feature that is nice to have.

Also, could you help me to close the issue #214 ? Either I cannot do it myself or I haven't seen how to remove the Py3.8 from the project badge. Much appreciated.

P.S. Could you lay out your reasons why moving from PDM to UV? Just curious.

[Tinche]

I recently ported a different project of mine to uv, maybe you can use that as guidance: Tinche/incant#18 (no need to also introduce Just, that's a different change).

We want to test on betas to see where we stand. It's also possible CPython breaks something in the new version and they need to know about it. Usually adding a new Python version is quite straightforward, if it's not we can hold off on merging the PR.

The badge should update when we release the next version, I think it goes to PyPI for this metadata.

[Tinche]

Thanks!

[stankudrow]

I recently ported a different project of mine to uv, maybe you can use that as guidance: Tinche/incant#18 (no need to also introduce Just, that's a different change).

We want to test on betas to see where we stand. It's also possible CPython breaks something in the new version and they need to know about it. Usually adding a new Python version is quite straightforward, if it's not we can hold off on merging the PR.

The badge should update when we release the next version, I think it goes to PyPI for this metadata.

Thank you, I'll open a PR and, if things will go smoothly, I hope in one PR both uv and Py3.14 will be viable.