Compatibility with Niquests
Ousret opened this issue · comments
Hello,
I am writing to see if there would be room for a potential improvement. It is also an opportunity to showcase this http client to Sentry folks.
"responses" is highly bound to Requests and I wondered if there was a possibility to allow a "drop-in" compatibility with Niquests.
Today, the only way to make it work outside of Requests is to tamper with sys.module, which is kind of unreasonable.
I have several option that can be considered without any default behavior breakage
A) Precedence
try:
from niquests.adapters import HTTPAdapter
from niquests.adapters import MaxRetryError
from niquests.exceptions import ConnectionError
from niquests.exceptions import RetryError
except ImportError:
from requests.adapters import HTTPAdapter
from requests.adapters import MaxRetryError
from requests.exceptions import ConnectionError
from requests.exceptions import RetryError
B) Environment
RESPONSES_BACKEND_NIQUESTS=1 pytest tests/
C) Expose kwarg in annotations
@responses.activate(for_niquests=True)
def ...
Of course if none suit you, feel free to close it.
I am willing to propose a PR.
Regards,
There are quite a few imports from requests
in responses so I don't know if a decorator based solution will work with the current implementation. We could potentially have a module that exposes the necessary interfaces from the library that responses is going to intercept.
Another alternative for choosing the library would be to have global methods that let the library be chosen, and default to requests for compatibility.
import niquests
import responses
responses.intercept(niquests)
At sentry we're still using requests, and don't have much additional time to devote to supporting alternative clients that we aren't also using.
I am more concerned on the different side. niquests
promises compatibility with requests now. What is that promise will be broken. Then responses
have to catch up and support two libs
Another alternative for choosing the library would be to have global methods that let the library be chosen, and default to requests for compatibility.
Would work fine.
At sentry we're still using requests, and don't have much additional time to devote to supporting alternative clients that we aren't also using.
Understandable. Who knows what the future reserve. I suppose that only a major event would make Sentry consider dropping Requests.
I am more concerned on the different side. niquests promises compatibility with requests now. What is that promise will be broken. Then responses have to catch up and support two libs
That reasoning apply with requests, and underlying urllib3. And by the look of it, you don't restraint either requests and urllib3.
As far as Niquests is concerned, semver apply, if the compat would break, then Niquests would lost its main interest...
It's unclear, just to be sure, are you willing to accept a PR to have global methods that let the library be chosen
?
If not, it's okay, feel free to close this one.
regards,
you can propose the PR. Ideally, it should be a way for the user to control which modules to use. For a time being please implement using internal method _method