Lock flask version

[T4rk1n]

Recent versions of flask/werkzeug have introduced breaking bugs in dash. This PR lock the versions of flask/werkzeug installed in order to prevent further breakage.

[alexcjohnson]

Forum post discussing the motivations for this PR: https://community.plotly.com/t/dash-is-planning-to-lock-flask-werkzeug-versions/74829

[moorepants]

I saw the recent forum post and just wanted to express that I don't think this is a good idea. The general reason is explained in this blog post: https://iscinumpy.dev/post/bound-version-constraints/. Dash is used as a library when we build applications and we need to be able to mix versions of dependencies as flexibly as possible. Making a decision like this may seem like a good idea from the perspective of a dash developer, but for users it will cause headaches. I think a better approach is to use the same >= pin you used before but bump the version of flask up and make dash robust to a set of flask versions. I maintain the dash conda package and this will also make it virtually impossible to install dash alongside other packages that depend on flask.

[alexcjohnson]

Thanks @moorepants - I pointed to exactly that post last year in plotly/jupyter-dash#87 (comment) when this same issue came up with Flask/Werkzeug 2.1. We've really tried hard to stick to that stance, but it's now been three minor versions in a row that caused different breaking changes for Dash. We need to acknowledge that the great majority of Dash users don't care what version of Flask they're using - many don't even know they're using Flask. So this is causing lots of users' code to break unnecessarily, causing us ongoing headaches trying to help them and scramble to update our code, and only helping the small fraction of Dash users who use Dash within another Flask app.

We're investigating what we can do to make life easier for our majority use case while still allowing Flask to float for the Dash-in-a-Flask-app use case (with the caveat that you're on your own if you end up with a version different from the officially supported one). It might mean a separate package (dash-core?) that doesn't pin Flask, while the primary dash package does. We're open to any ideas you have, but one way or another the status quo is not sustainable.

[moorepants]

The idea I have is to follow the same method as most all other Python libraries. Pin with >= and if a new release of a dependency breaks Dash, then update Dash to deal with the change. If a Dash user experiences a break when they update dependencies in their environment, then they can make an == or <= pin there until Dash is patched. If Dash users don't want their app to break, they shouldn't update dependencies.

[alexcjohnson]

That’s exactly what we have been doing until now. But with regards to Flask specifically that philosophy is not working.

[T4rk1n]

Closing in favor of #2538