Upper bound on Flask and Werkzeug versions #2538
Conversation
|
Working on it, I'll address this in this PR as well. |
CHANGELOG.md
Outdated
| @@ -4,6 +4,10 @@ This project adheres to [Semantic Versioning](https://semver.org/). | |||
|
|
|||
| ## [UNRELEASED] | |||
|
|
|||
| ## Changed | |||
|
|
|||
| - [#2538](https://github.com/plotly/dash/pull/2538) Add an upper bound to Flask and Werkzeug versions at `<2.2.3`, to reflect the fact that we expect the Dash ecosystem to be incompatible with the next minor release of Flask. This excludes the current latest Flask release 2.3.x, we will raise that to `<2.4` after we fix incompatibilities elsewhere in the Dash ecosystem. | |||
There was a problem hiding this comment.
Nitpicking but there's a comma splice in the second sentence. I'd suggest different punctuation, but it's not clear to me how the two clauses relate to each other―if they don't really, maybe something like
Add an upper bound to Flask and Werkzeug versions at <2.2.3 because we expect the Dash ecosystem to be incompatible with the next minor release of Flask (this excludes the current latest Flask release 2.3.x). We will raise the upper bound to <2.4 after we fix incompatibilities elsewhere in the Dash ecosystem.
There was a problem hiding this comment.
updated in c25225b - thanks @red-patience!
Ironically the TS upgrade isn't what caused the TS errors, AFAICT that was primarily the Ramda upgrade
with corresponding ts updates due mainly to Ramda
| @@ -76,7 +76,7 @@ export function getPath(paths, id) { | |||
| return false; | |||
| } | |||
| const values = props(keys, id); | |||
| const pathObj = find(propEq('values', values), keyPaths); | |||
| const pathObj = find(propEq(values, 'values'), keyPaths); | |||
There was a problem hiding this comment.
Ah it was inverted, strange because it feel more natural with the prop name first.
A less drastic alternative to #2516 - simply set an upper bound on Flask and Werkzeug at versions that we've tested thoroughly and we know work.
We're well aware of the arguments against upper version bounds - articulated most clearly perhaps in https://iscinumpy.dev/post/bound-version-constraints/ - let me just point out one line in the intro of that piece:
I think we have ample evidence at this point that this is such a place. From our experience with the last several Flask minor releases, this particular upper bound expresses a true statement about Flask & Dash: We expect the Dash ecosystem to be incompatible with the next minor release of Flask. We know that this is true for Flask 2.3 already, and we are working to fix the incompatibilities in our related libraries, after which we will bump these upper limits to
<2.4. Note that we need to limit both Flask and Werkzeug, because even though they're normally released synchronously with matching version numbers, Flask depends onWerkzeug>={matching version}After we make this change, we will institute a process upon every new Flask minor release where we thoroughly test it across the Dash ecosystem, make any required changes, and then bump the upper version constraint. In general we will bump to
<{next minor}rather than<={known good patch}as we're doing here, just because the later patchesFlask@2.2.4andFlask@2.2.5that currently exist are primarily about forward compatibility withWerkzeug@2.3.xwhich we are not supporting in the upcoming Dash release.CHANGELOG.md