Why doesn't flask set an upper bound for any dependencies?

[aabmass]

From the Flask/Werkzeug 3 release, there were several issues related to Flask 2.x users having Werkzeug 3 pulled in and getting runtime errors:

• Flask setup.py should use "Werkzeug ~= 2.2.2" instead of "Werkzeug >= 2.2.2" #5285
• Issue with Werkzeug bump #5279
• Got error using flak Flask==2.0.2 #5277

I know that pinning/locking dependencies solves the issue from a CI perspective. However, this specific issue with Werkzeug wouldn't have happened if Flask set an upper bound on its direct dependencies:

flask/pyproject.toml

Lines 23 to 28 in 1423251

	"Werkzeug>=3.0.0",
	"Jinja2>=3.1.2",
	"itsdangerous>=2.1.2",
	"click>=8.1.3",
	"blinker>=1.6.2",
	"importlib-metadata>=3.6.0; python_version < '3.10'",

It also impacted libraries that use Flask (e.g. plugins, instrumentation) which don't generally pin transitive dependencies. This looks like a conscious decision. Why doesn't flask set an upper bound for any dependencies?

[ThiefMaster]

Copying @davidism's comment from various issues first of all:

When writing an application, you must use a tool like pip-tools to pin your application's full dependency tree. This gives you reproducible deployments, allowing you to control when you get updates. Be sure to run your tests with deprecation warnings treated as errors so that you get notified of those types of changes early.

Please review any of the following for more information:

• https://hynek.me/articles/semver-will-not-save-you/
• https://www.youtube.com/watch?v=WSVFw-3ssXM&t
• https://snarky.ca/why-i-dont-like-semver/
• https://caremad.io/posts/2016/02/versioning-software/
• https://bernat.tech/posts/version-numbers/
• https://iscinumpy.dev/post/bound-version-constraints/

---

You are completely right that libraries should not pin dependencies - but the end applications that do use those libraries should absolutely do it, and by pinning transitive dependencies, they ensure that they do not end up with something like "flask 2 + werkzeug 3".

Of course any new application should not use outdated versions, so a new application should be installing the latest flask, which pulls in the latest werkzeug, and at that point they are compatible with each other - and then you pin those dependencies to have a working set.

At a later point you can easily use something like pip-compile to update your deps and test if things still work as they should using those latest versions.

[aabmass]

https://iscinumpy.dev/post/bound-version-constraints/#tldr was useful to understand the approach here. I agree that dependency resolver conflicts are a huge headache in the python ecosystem, and seems worthwhile to avoid. It did mention cases where capping might be reasonable:

If you have a heavy dependency on a library, maybe cap. A really large API surface is more likely to be hit by the possible breakage.
...
You could probably summarize it like this: if there’s a high chance (say 75%+) that a dependency will break for you when it updates, you can add a cap.

I'm not familiar with Flask internals so don't know how applicable this is. I'm not trying to convince anyone anyway 😃

Thanks for the quick reply, I think this answers the question.