v4.0 - requests, niquests, httpx or something else?

[tobixen]

This is a continuation of #457

My final conclusion in #457 was that I would make niquests an explicit dependency in pyproject.toml, but since this may be controversial (ref #530) ensure that things still works if someone forks the project and simply changes on the dependencies in pyproject.toml. I also conluded that I would reconsider before releasing v4.0.

(v3.0 is still on the drawing board has been released, v4.0 is probably coming out in 2027).

[lilydjwg]

FYI there is a fork called httpxyz because httpx has closed its issues and discussions, and no new releases since more than one year ago.

[tobixen]

Thanks for the heads-up. The maintainer of Niquests was warning for a while about issues and stagnant development of the httpx-library, but since neither my community nor the HomeAssistant community considered httpx to be the best library around I somehow thought he was overdoing it. Weird that there should be so much drama in the Python HTTP community.

[tobixen]

The reddit thread describes httpx as a supply-chain risk.

Currently the async code will choose httpx if it's available, otherwise use niquests. I should flip that.

[dotlambda]

Maybe pyreqwest is an alternative to consider.

[lilydjwg]

I no longer consider niquests as an acceptable HTTP client library for my own use, because it depends on urllib3.future, which attempts to replace the files on disk of urllib3 with itself. Linux package managers can't handle this kind of behavior, and it may cause hard-to-figure-out issues for software using urllib3 when an incompatibility is encountered.

Edit: the replace behavior can be opted out when installing. Nevertheless it would still create two different behaviors that could accidentally mess things up if not enough care is taken.

[tobixen]

Yes, you're not the first to raise this issue, hence there are fallbacks to httpx and requests libraries. The other maintainer to raise this issue claimed that he was fine this, even if it potentially means he'll have to patch the dependencies in pyproject.toml.

I don't have the overview, the niquests developer seems to consider that there is no issue. I find it weird it's so much drama in the python http space, and also weird that the changes provided in niquests and urllib3.future hasn't been accepted into the requests and urllib3 libraries. The changes looks good to me. The urllib3 vendors have been begging for many years already for money for getting HTTP/2 done, it's visible in every changelog. The amount of money they want is peanuts compared to a government procurement standards, but it's really huge amount of money compared to the coffee money many of us Open Source developers are happy with. I really don't know what's going on here, but to me niquests (with HTTP/2 support and many other things) seems to be the better choice.

[tobixen]

I will fix the fallback logic to include httpxyz as well.