Flask socketio breaks with new version of Werkzeug (2.1.*)

[yogevyuval]

Describe the bug Flask socketio breaks with new version of Werkzeug (2.1.*) https://github.com/pallets/werkzeug/pull/2276 This is the exception:

from flask_socketio import disconnect
File "/usr/local/lib/python3.8/site-packages/flask_socketio/__init__.py", line 24, in <module>
from werkzeug.serving import run_with_reloader
ImportError: cannot import name 'run_with_reloader' from 'werkzeug.serving' (/usr/local/lib/python3.8/site-packages/werkzeug/serving.py)

From the code, it seems that the library is using the function run_with_reloader , however it is a private function that was deprecated.

To Reproduce Steps to reproduce the behavior:

1. Install fresh flask socketio with werkzeug (2.1.*)
2. Import flask socketio
3. See error

Expected behavior The library should not use the private function

[miguelgrinberg]

If you want to use the Werkzeug reloader, then upgrade Flask-SocketIO or downgrade Werkzeug. This issue was resolved long ago, you only see it because you are using an old Flask-SocketIO release.

If you are unhappy that a private function is being used to use the reloader, then I share your feelings, but this is the only way for me to use Werkzeug's reloader, since the project has decided to make it private. The only solution that you have is to opt out of using the Werkzeug reloader, and then you shouldn't have any problem.

[yogevyuval]

@miguelgrinberg I understand what you are saying and I agree! I'll test again with a new Flask-SocketIO version and close this if it solves the case. Thanks

[idcrook]

"downgrade Werkzeug"

Is there a quick and dirty way I can do this in a requirements.txt file that needs to use version 4? It is pinning latest 4.x version

flask-socketio==4.3.2

tagging for https://github.com/idcrook/shairport-sync-mqtt-display/issues/44

[idcrook]

"downgrade Werkzeug"

Is there a quick and dirty way I can do this in a requirements.txt file that needs to use version 4? It is pinning latest 4.x version

I found something that works for me. Pin in requirements.txt

--- a/python-flask-socketio-server/requirements.txt
+++ b/python-flask-socketio-server/requirements.txt
@@ -1,4 +1,5 @@
 flask
+Werkzeug==2.0.1
 flask-socketio==4.3.2
 # wheel should not be needed, but avoids pyyaml paho-mqtt bdist_wheel error
 wheel

And (in a fresh venv) make sure pip doesn't used the newer cached version (2.1.2) but pulls the version specified in requirements.txt.

pip install --no-cache-dir -r requirements.txt

[bluthen]

If you want to use the Werkzeug reloader, then upgrade Flask-SocketIO or downgrade Werkzeug. This issue was resolved long ago, you only see it because you are using an old Flask-SocketIO release.

If you are unhappy that a private function is being used to use the reloader, then I share your feelings, but this is the only way for me to use Werkzeug's reloader, since the project has decided to make it private. The only solution that you have is to opt out of using the Werkzeug reloader, and then you shouldn't have any problem.

I was hoping to update Flask/Werkzeug but keep compatibility with socket.io js library 2.x

I'm okay not using the reloader, but because the import is not wrapped in try/except or if use_reloader you would still get an exception.

Would you accept a PR for 4.x version, or only developing 5.x going forward?

Edit: I think that answer is no.

https://github.com/miguelgrinberg/Flask-SocketIO/issues/1809

Edit2:

Non-recommended Workaround for anyone in my situation:

Place before importing flask-socketio

import werkzeug
import werkzeug.serving
import werkzeug._reloader

werkzeug.serving.run_with_reloader = werkzeug._reloader.run_with_reloader

Make sure to test your app obviously.

[miguelgrinberg]

@bluthen The 4.x release of this package is not active, neither are the legacy dependencies it needs. There is no reason in 2023 to use the legacy Socket.IO protocol in my opinion, which has been obsoleted more than two years ago. If you are being forced by a server that refuses to upgrade, then put pressure on the owner of the server.

Of course my choice to not support these legacy releases does not prevent you from maintaining your own fork, or applying any import hacks if you feel comfortable maintaining these solutions.