Breaking change in 2.1.0

[yvsppt]

After installing a tiers tool, this error occured:

File "C:\Users\yves.pipault\AppData\Roaming\Python\Python310\site-packages\jinja2\utils.py", line 642, in
from markupsafe import Markup, escape, soft_unicode

Environment:

• Python version: 3.10
• MarkupSafe version: 2.1.0

Workaround:
pip install markupsafe==2.0.1

According to changelog of version 2.1.0, we can read:

Remove soft_unicode, which was previously deprecated. Use soft_str instead. #261

That is a BREAKING CHANGE so you SHOULD increase the MAJOR version according to semantic versionning: https://semver.org/

[sphuber]

That is a BREAKING CHANGE so you SHOULD increase the MAJOR version according to semantic versionning

Not necessarily defending the choice of including a breaking change in a minor revision, but even if it had been a major release it would have still broken jinja2 since they have the requirement markupsafe>=0.23 and so do not provide an upper limit.

[pradyunsg]

Hi there! I'm not a maintainer of markupsafe, but I will note that this project does not mention SemVer or Semantic versioning anywhere in it.

https://github.com/pallets/markupsafe/search?q=semantic+versioning
https://github.com/pallets/markupsafe/search?q=semver

The deprecation message clearly noted that this attribute was going to be removed in 2.1:

https://github.com/pallets/markupsafe/blob/2.0.x/src/markupsafe/_native.py#L71

Your application has likely been printing a warning every single time you've used Jinja2 as well, about this deprecation. If not, you might want to look into how you can catch these DeprecationWarnings before they break you.

---

Beyond that, I'll note that this blog post about SemVer is pretty relevant. Broadly, the responsibility of protecting against upstream releases causing a breakage in your workflow is on you; not on the library maintainers.

jinja2 since they have the requirement markupsafe>=0.23 and so do not provide an upper limit.

And I'd argue that's the right thing to do. The blog post above goes into why you shouldn't have upper pins on your libraries and why you should have exact pins in your applications. Here's a much longer form blog post talking about the consequences of doing upper caps in libraries (it's bad).

[MetRonnie]

Your application has likely been printing a warning every single time you've used Jinja2 as well, about this deprecation. If not, you might want to look into how you can catch these DeprecationWarnings before they break you.

Jinja2 is under the same organisation as this repo - https://github.com/pallets/jinja/

[pradyunsg]

What's the point you're trying to make? You realise this only happens on unsupported versions of Jinja2 right?

pallets/jinja#1585 (comment)

[davidism]

Duplicate of #282

You are using an unsupported version of Jinja, please update to the latest version. Additionally, please read https://hynek.me/articles/semver-will-not-save-you/, then use a tool like pip-tools to pin your dependencies and control when you get updates. Be sure to run your tests with deprecation warnings treated as errors so that you get notified of these types of changes early.

[MetRonnie]

Your application has likely been printing a warning every single time you've used Jinja2 as well, about this deprecation. If not, you might want to look into how you can catch these DeprecationWarnings before they break you.

Jinja2 is under the same organisation as this repo - https://github.com/pallets/jinja/

What's the point you're trying to make? You realise this only happens on unsupported versions of Jinja2 right?

Sorry, I somewhat misunderstood what you meant (thought you meant the Jinja2 team should have been aware of the deprecation warnings).

But we haven't been getting any deprecation warnings in Jinja2 2.11.3 (MarkupSafe 2.0.1). Tried export PYTHONWARNINGS=error (always too) and running our program (https://github.com/cylc/cylc-flow), nothing came up. I have had a look and don't think we're doing anything to swallow warnings.

[thetic]

You are using an unsupported version of Jinja.

May I ask where this is communicated? I would like to stay up to date on supported versions.

[davidism]

The only supported version is the latest version (2.1.x) which receives bug fixes. The development version (main) receives features and merges in bug fixes, but it's not "supported" since it's not a stable release. This is true for all the Pallets projects.

[thetic]

is this documented anywhere?

[pradyunsg]

It’s the implied contract for most OSS projects. See https://bernat.tech/posts/version-numbers, specifically What’s the problem with semantic versioning? — If there’s no documented stability policy, the implied stability policy is what @davidism noted above: only the latest release is “supported”, to the extent support is even promised by an OSS project that you aren’t funding.

See the license, and specifically what the warranties it notes.