Why override flask run?

[maxnoe]

This was really unexpected to me. Just having flask-socketio installed breaks FLASK_DEBUG=true because it overrides the flask run command.

Why is this done and is this really necessary?

[miguelgrinberg]

It isn't supposed to break anything. Can you describe what is the problem that you found?

The reason flask run is overriden is that Flask-SocketIO tries to use a web server that supports WebSocket if available.

[maxnoe]

See pallets/flask#2200

[miguelgrinberg]

@maxnoe I can't reproduce that error with latest versions of Flask and Flask-SocketIO and my own test application. Do you have a simple example I can try here, and the output of pip freeze in your virtual environment? I hope that should be enough for me to reproduce this problem.

[maxnoe]

$ pip freeze
click==6.7
Flask==1.0.2
Flask-SocketIO==3.0.0
itsdangerous==0.24
Jinja2==2.10
MarkupSafe==1.0
python-engineio==2.1.1
python-socketio==1.9.0
six==1.11.0
Werkzeug==0.14.1

Having this issue inside a minimal installation using pipenv and only flask and flask_socketio with the flask hello world app.

[miguelgrinberg]

Oh, so you installed Flask-SocketIO in your virtualenv but are not using it in the application?

[maxnoe]

Yes, pretty uncommon, I know. But nevertheless unexpected.

[maxnoe]

I ran into this, when I started a new Project and intstalled flask_socketio but wasn't using it yet.

[miguelgrinberg]

Should be fixed in release 3.0.1.

[miguelgrinberg]

This fix was undone, as it affects the operation of the reloader for normal apps. Will need to find a different way to address this problem.

[Kamforka]

Have the same issue. It's quite unorthodox for a pip install to break my app :D

[miguelgrinberg]

@Kamforka yes, I apologize for that. This used to work fine with Flask < 1.0 versions, but some changes that went into that release are incompatible with my solution.

[Kamforka]

@miguelgrinberg is the fix in progress or you welcome contributors to sort it out?

[miguelgrinberg]

This isn't at the top of my list at this time, given that it has a very easy workaround (i.e. uninstall Flask-SocketIO if you are not using it!). You are welcome to look into it.

[GlennG2012]

Hey, I don't know if this helps. But rather than installing/uninstalling flask-socketio, place if name == 'main': socketio.run(app) on applications that uses it, and then app.run() on those that don't. rather than flask run, do 'python application.py' on terminal instead

[Kamforka]

@GlennG2012 thanks for the suggestion, however our deployment relies on flask run and it was causing problem during the onboarding of Flask-SocketIO whereas on one branch we had an app without socketio and on an other we had with socketio and of course the package was already installed in the virtual environment. Now that those branches - without socketio - are extinct it's not a huge deal any more, just inconvenient for a fresh start.

[miguelgrinberg]

Starting with Flask-SocketIO 3.2.0 (just released), the flask run command can only be used with the threading mode. For all other async modes, the socketio.run(app) method should be used to start the server.

[Kamforka]

Is it necessary to drop compatibility with complex applications which use the .init_app() method to setup extensions?
Isn't there a way to check in the modified flask run if the app has a registered socket io extension?

[miguelgrinberg]

@Kamforka that can all be done. What cannot be done easily is to pass through control from my modified run to the original run in the cases where this is necessary. I can't also automatically change my modified run function to match changes made to the Flask run command. When this happens my function breaks and I need to put out the fire. It brings me a lot of unhappiness, and all to support a way of starting the server that I don't even like.