The ngrok-api package hard-specifies a version of requests, which is 2 years back. This specification model causes problems with pip and especially poetry. Pip displays a warning during installation if a newer application package is installed in the virtual environment. Poetry prohibits installation.
Because no versions of ngrok-api match >0.8.0,<0.9.0
and ngrok-api (0.8.0) depends on requests (2.25.1), ngrok-api (>=0.8.0,<0.9.0) requires requests (2.25.1).
And because [...] depends on requests (>=2.28.2,<3.0.0)
and no versions of [...] match >1.1.2,<2.0.0, ngrok-api (>=0.8.0,<0.9.0) is incompatible with [...] (>=1.1.2,<2.0.0).
So, because [xxxx] depends on both [...] (^1.1.2) and ngrok-api (^0.8.0), version solving failed.
I would like to implement one of the 2 following solutions :
Strategy 1 : Could you declare this dependency by authorizing the use of intermediate version (^2.25.1 instead of ==2.25.1). Knowing that in case of warning with pip, this is already what is done. We're running ngrok-api with a newer version of requests ?
Strategy 2 : Could you update the requests package used more regularly ?
I'm facing similar issue.
ngrok-api (0.12.0) requires requests (2.25.1).
fastembed (0.3.6) requires requests (>=2.31,<3.0).
Any chance on having requests updated to later version?
Thanks.
The ngrok-api package hard-specifies a version of requests, which is 2 years back. This specification model causes problems with pip and especially poetry. Pip displays a warning during installation if a newer application package is installed in the virtual environment. Poetry prohibits installation.
I would like to implement one of the 2 following solutions :
Strategy 1 : Could you declare this dependency by authorizing the use of intermediate version (^2.25.1 instead of ==2.25.1). Knowing that in case of warning with pip, this is already what is done. We're running ngrok-api with a newer version of requests ?
Strategy 2 : Could you update the requests package used more regularly ?
Thanks a lot for your work.