Skip to content
This repository has been archived by the owner on Jan 29, 2024. It is now read-only.

Deal with a deprecation warning coming from responses=0.17.0 #543

Closed
jankrepl opened this issue Jan 11, 2022 · 2 comments · Fixed by #546
Closed

Deal with a deprecation warning coming from responses=0.17.0 #543

jankrepl opened this issue Jan 11, 2022 · 2 comments · Fixed by #546
Assignees
Labels
🐛 bug fix Something isn't working

Comments

@jankrepl
Copy link
Contributor

🐛 Bug description

I manually triggered a CI run on master https://github.com/BlueBrain/Search/actions/runs/1681998905 and it failed.

It seems to be because of the brand new responses=0.17.0 (https://pypi.org/project/responses/#history). It seems like some of its functionality we use inside of bluesearch is going to be deprecated. Note that we are turning all warnings into errors when running unit tests.

Search/tox.ini

Lines 140 to 141 in 195aebe

filterwarnings =
error

@jankrepl jankrepl added the 🐛 bug fix Something isn't working label Jan 11, 2022
@jankrepl jankrepl self-assigned this Jan 12, 2022
@jankrepl
Copy link
Contributor Author

jankrepl commented Jan 12, 2022

Actually, the reason why the DeprecationWarning is raised appears to be a bug inside of the responses==0.17.0. For more details see getsentry/responses#464

Potential solutions

  1. Temporarily pin the responses package from above (<0.17.0) and wait until a new version with a fix is released
  2. Manually pass match_querystring=None whenever using add_callback(as done here pretix/pretix@8ae4304)
  3. Temporarily ignore all depracation warnings coming from responsesand wait until a new version with a fix is released

Feel free to suggest other solutions!

@FrancescoCasalegno
Copy link
Contributor

Hi @jankrepl ,

Thanks for the analysis of the problem!

From what the authors of responses replied in getsentry/responses#464 (comment) I have the feeling that until 1.0.0 we may not have a fix to be released, so I would exclude solution 1. and 3..

On the other hand, 2. is what they recommend to do again in getsentry/responses#464 (comment). The impact should on our code should also be reasonable (16 lines of code to add in total).

So I would go with 2.! 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🐛 bug fix Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants