[BUG] Dash 1.19.0 incompatible with latest release of Flask 2.2.2

[aGitForEveryone]

Using Python 3.8 I find that the latest version of Flask (currently 2.2.2) is incompatible with older versions of Dash (in my case I only tested 1.19.0)

This problem pops up when installing a virtual environment for older Dash tools where the version of Flask is not pinned. Starting with an empty venv and installing Dash 1.19.0 is enough to reconstruct the error:

pip install dash==1.19.0 Werkzeug==2.0.2

(pinning the version of Werkzeug because of the traceback bug that was solved in Dash 2.3.1)

Now in any Python environment, simply type import dash and the following error appears

  File "<my_env>\dash\__init__.py", line 5, in <module>
    from .dash import Dash, no_update  # noqa: F401,E402
  File "<my_env>\dash\dash.py", line 20, in <module>
    import flask
  File "<my_env>\flask\__init__.py", line 4, in <module>
    from . import json as json
  File "<my_env>\flask\json\__init__.py", line 8, in <module>
    from ..globals import current_app
  File "<my_env>\flask\globals.py", line 56, in <module>
    app_ctx: "AppContext" = LocalProxy(  # type: ignore[assignment]
TypeError: __init__() got an unexpected keyword argument 'unbound_message'

If I then downgrade the version of Flask to 2.1.3, importing Dash is successful again.

Note: There are no compatibility issues when using Dash 2.6.1

Suggested solution I guess this issue can be solved by limiting Flask to 2.1.3 for the older Dash versions.

[alexcjohnson]

Flask and its dependencies / sub-packages are a major pain for us, given the very different concept of SemVer they have than most other packages. We can't do anything about previously published versions of Dash, v1.19.0 can't retroactively change the requirements it declared, and even going forward it would be inappropriate for us as a library to declare the current version of Flask et al to be the greatest that we support. FWIW we had much more problems when Flask released v2.2 than we did with Flask v2.0!

The most robust solution I can recommend is for projects to maintain two requirements files: one (sometimes called requirements.in) that just declares direct dependencies as installed during development, then you pip freeze these into requirements.txt that pins exact versions of all dependencies and sub-dependencies, and is used to recreate the exact previous environment or when deploying to production.