Flask 1.0 Release - Impact On Your Dash Apps

[chriddyp]

Hello Dash Community!

Flask 1.0 was released recently This is a major version release which means that it contains breaking changes. I wanted to create this thread to document which changes in Flask 1.0 affect Dash.

Here is the official Flask 1.0 Changelog: http://flask.pocoo.org/docs/1.0/changelog/

Of those changes, these are the ones that may affect Dash users:

Python 2.6 and 3.3 are no longer supported. (pallets/meta#24)

Dash is only explicitly tested on Python 2.7 and Python 3.6, so this shouldn’t affect anyone.

The development server uses threads by default. (#2529)

Previously, dash users may have used app.run_server(threaded=True). This is now default. Practically speaking, this means that Dash apps can serve multiple callbacks in parallel by default. Note that in production environments, you should serve your app with gunicorn.

This is another reminder to keep your backends stateless (no mutable global variables!) so that your apps can run seamlessly in multi-threaded or multi-process environments. Dash Documentation & User Guide | Plotly for more info.

Flask.logger has been simplified. LOGGER_NAME and LOGGER_HANDLER_POLICY config was removed. The logger is always named flask.app. The level is only set on first access, it doesn’t check Flask.debug each time. Only one format is used, not different ones depending on Flask.debug. No handlers are removed, and a handler is only added if no handlers are already configured. (#2436)

Dash doesn’t use Flask.logger explicitly but we’ve discussed how to incorporate Flask.logger in some community threads: Suppress Dash server posts to console - #5 by nedned, Redirect Logging to File / Directory - #2 by chriddyp.

Fix incorrect JSON encoding of aware, non-UTC datetimes. (#2374)

Dash uses the plotly.utils.PlotlyJSONEncoder, so I don’t think that Dash is affected by this change (see here: dash/dash/dash.py at 3dfa941fbba79efafc397360520f5a8e964236f6 · plotly/dash · GitHub)

The flask command and Flask.run() will load environment variables from .env and .flaskenv files if python-dotenv is installed. (#2416)

This doesn’t affect any existing apps, but is a nice new feature

---

I think that’s it. If I’m missing anything, please comment

[radekwlsk]

So it is safe to say that Flask 1.0.* can be used safely with Dash if project has no direct use of Flask features?

[chriddyp]

I’d say so! I’ve been using it in my own apps and client’s apps for a few weeks now.

[Abeserra]

I just updated the Flask backend module for my Dash app to Flask==1.0.3 and now when I run the app locally I get this:

* Environment: production
WARNING: Do not use the development server in a production environment.
Use a production WSGI server instead.
* Debug mode: on

So, I’m running the Dash app with app.run_server(debug=True) and it does automatic reloading upon changes in source code, but apparently for Flask the server it’s running in “Production” environment. Moreover, if I launch the app setting FLASK_ENV to development (export FLASK_ENV=development) it changes to development environment I don’t get the warning regarding the underlying server, and the automatic reloading is working as well.

I’m confused: What’s the right choice: to set this variable to ‘development’ for developing in local Dash apps or better to keep it “as it is” by Dash (using the debug parameter only)?.
Anyway it would be nice to have something done from the Dash side in order to not get that confusing warning and to make sure we are in the right environment. Maybe document it somewhere?

[chriddyp]

The arguments in run_server are passed directly through to flask: https://github.com/plotly/dash/blob/7219b3d9f827e95bbbace801aa955b8c21ff8ffe/dash/dash.py#L952-L956

[Abeserra]

OK, so according to the Flask documentation:

This works well for the common case but it does not work well for development which is why from Flask 0.11 onwards the flask method is recommended. The reason for this is that due to how the reload mechanism works there are some bizarre side-effects (like executing certain code twice, sometimes crashing without message or dying when a syntax or import error happens).

We should use FLASK_ENV=development for local development.