Replace requests with niquests or httpx?

[tobixen]

@ArtemIsmagilov suggested to replace the requests library with niquests in #455, and raised my awareness that the requests library is likely at a dead end. I'm a bit wary of changes here, for two reasons:

• The authorization part is very fragile due to weird server setups - several time I've been doing minor changes here, and long time after it has been released as part of HomeAssistant, and people start complaining.
• Due to recent supply-chain attacks I'm wary of adding new dependencies. So far the niquests package is maintained by one maintainer and has gotten relatively few eyeballs.

So I've decided that this change will be merged into the master branch, but only be released officially in version 2.0 of the library. I assume there will be at least a 1.5-release before that still based on requests.

Then @sim0nx suggested using httpx rather than niquests, as this package has been around for a while, has more maintainers and basically has the same feature set.

I raise this issue to allow people to drop thoughts on this.

(as for the requests library, the 2.x-version line has been in a feature freeze for ages, 3.0-version is long overdue. I also found that the project owner has received a significant amount of fundraised money to get 3.0 done. It may seem like the money has been spent without significant visible progress on getting 3.0 released. Among the things needed is a possibility for doing things async, support for HTTP/2 and various other things. I also think the authentication code belongs to the requests-library and not in the CalDAV library)

[tobixen]

I have an impression that HomeAssistant is one of the main drivers of end users to the caldav project. They already have httpx and aiohttp (and requests) in the dependency list, but not niquests. To get upgrades smoothly into the homeassistant project I suppose httpx is preferred. I suppose all the code has to be rewritten to be async to be able to use aiohttp, while with httpx (and niquests) it will be possible to develop the library so that users can use it both in a synchronous and asynchronous manner. I suppose. Haven't looked much into it yet.

[alexbarcelo]

I was recently looking for a CalDAV library for a Python project of my own, found this, and was sad when I realized that it has no support for async and I would have to hack a little bit a thread or something to make everything work together.

httpx is quite popular and allows to have synchronous and asynchronous with a more or less cohesive and unified dependency tree. I know that supporting both is a pain, as there is the need to repeat a little bit code because of async/await additions in the source code and some ugly conditionals here and there. But I assume that supporting both interfaces is important for this caldav library (there are legit use cases in both sides, sync and async). And the conditionals should be plain and easy to read, ugly but understandable.

[tobixen]

I got recommended to try and switch the requests library with httpx, but I also found that the httpx library is very strict and non-pragmatic when it comes to supporting the jungle of http servers out there. I don't remember the details, but I when I did research into it, I considered it to be a high risk that it will break up the compatibility of the library. It would also most likely be needed to rewrite quite much to get httpx to work.

It should supposedly be possible to use niquests in a asynchronous way. I haven't done any research into that. I'd very much appreciate any help making support for async - but yes, it will be needed to support sync for a long time to come, and for me "backward compatibility" is a big thing.