Compatibility with Niquests

[Ousret]

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,

[markstory]

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.

[beliaev-maksim]

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

[Ousret]

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...

[Ousret]

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,

[beliaev-maksim]

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