Model arguments to socketio.run() on those of app.run()

[fabswt]

Before Flask-WebSocketIO, I was able to start Flask like so:

app.run(
    debug=os.environ.get('FLASK_DEBUG'),
    host=os.environ.get('FLASK_RUN_HOST'),
    port=os.environ.get('FLASK_RUN_PORT'),
    ssl_context=(
        os.environ.get('FLASK_RUN_CERT'),
        os.environ.get('FLASK_RUN_KEY'),
    )
)

With Flask-WebSocketIO, I have to start it like so:

socketio.run(
    app,
    debug=os.environ.get('FLASK_DEBUG'),
    host=os.environ.get('FLASK_RUN_HOST'),
    port=int(os.environ.get('FLASK_RUN_PORT')),
    certfile=os.environ.get('FLASK_RUN_CERT'),
    keyfile=os.environ.get('FLASK_RUN_KEY'),
)

Mind int(), and ssl_context dropped in favor of certfile/keyfile.

• Without int(), I'd get: TypeError: 'str' object cannot be interpreted as an integer.
• With ssl_context, I'd end up with AttributeError: 'tuple' object has no attribute 'wrap_socket'.

Describe the solution you'd like

I would suggest updating the arguments to socketio.run() to accept the same as app.run() did for ease and comfort.

[miguelgrinberg]

Outside of app, debug, host and port, any arguments that you pass to socketio.run() are passed to the web server that you are using. Since three different web servers are supported, it would be difficult to support a uniform set of arguments that are internally converted to what each web server needs.

Also consider that Flask's app.run() is a) not for production use and b) sort of a moving target, as Flask developers routinely add/change/deprecate its arguments. So it isn't a good model to follow for Flask-SocketIO.