Bump anyio to ~3.0

[cauebs]

Closes #183

[cauebs]

Before

156 passed, 3 warnings in 7.43s

After

112 passed, 2 warnings in 4.89s

Now I'm trying to figure out why the number of tests decreased :eyes:

[cauebs]

Ah, support for Curio was dropped in 3.0 and the anyio pytest plugin generates fewer test cases.

[theelous3]

Well. This leaves us in a funny position.

Will have to think.

[tarcisioe]

Support for Curio was requested to be removed by David Beazley himself. Curio was also bringing some issues for anyio development since it differs a fair amount in API (that is mentioned in their FAQ). Not bumping version hinders development of other libraries and applications that depend on asks but would like to use anyio itself in later versions.

Of course I consider that bumping anyio version is likely a major version bump for asks as well, since a major backend is not being supported anymore. That being said, Curio's maintainer himself made it clear that he thinks Curio should not be used behind an abstraction layer.

P.S.: I don't personally think that whatever use of Curio the maintainer does not like should be abolished, since I believe he is actually the one who cannot "wish away" how people use his library. But since he is taking his time to ask for support to be dropped, Curio is causing friction on how anyio works, and anyio's maintainers decided to go on with dropping support, I don't see how staying on an older version of anyio helps in any way, but I think that many projects should, unfortunately, give some thought about whether or not supporting Curio is worth the time, since it is distancing itself from event loop portability and making it hard on purpose.

[tomwatson1024]

Not bumping version hinders development of other libraries and applications that depend on asks but would like to use anyio itself in later versions.

I've just hit this - I've got a dependency on both asks and a library that requires anyio ~3, meaning I'm stuck for the time being!

[space88man]

anyio 3.1.0 is released

[cauebs]

I strongly believe that the best course of action is to drop support for curio and bump asks' major version to 3.0 (an alternative is branching off into a new asks3 package, but I don't think that achieves much).

• It won't break existing code, because people can still use asks=^2 if they need curio support. (If people really need it, they can even help backport features and bug fixes from asks 3 to 2);

• Holding back on this will make it impossible to choose asks in the future, because other libraries are already upgrading anyio to version 3. It's not a minor annoyance: it causes unsolvable conflicts;

• As others have pointed out, curio is so niche that even its author is recommending that libraries stop supporting it.

I understand the hesitation, it sure is a significant change, but as I see it there's no way to avoid it.

[alex-dr]

@theelous3 Any plans to address this issue? Very sad to not be able to use your library in certain environments

[theelous3]

Hey.

As it stands for me the project is at an impass.

For now, I will accept the PR and give asks a major version bump so as to unblock you guys.

---

asks was primarily written to give curio http capabilities. Then trio evolved from curio. So I wrote multio, to give trio http capabilities.

Then anyio evolved from multio and httpx evolved from here and there. Ultimately - asks has probably run its course, and should more than likely be dropped for httpx support.

I am way busier IRL now than I was when I first wrote asks, and I don't have the time it would take to rewrite asks to the extent required to be competitive with newer libraries.

[theelous3]

Moving discussion to the issue, because this is far from done.

https://github.com/theelous3/asks/issues/183