Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking change in 2.1.0 #286

Closed
yvsppt opened this issue Feb 18, 2022 · 10 comments
Closed

Breaking change in 2.1.0 #286

yvsppt opened this issue Feb 18, 2022 · 10 comments

Comments

@yvsppt
Copy link

yvsppt commented Feb 18, 2022

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
Copy link

sphuber commented Feb 18, 2022

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
Copy link

pradyunsg commented Feb 18, 2022

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
Copy link

MetRonnie commented Feb 18, 2022

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
Copy link

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
Copy link
Member

davidism commented Feb 18, 2022

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.

valeros added a commit to platformio/platform-sifive that referenced this issue Feb 18, 2022
Jinja2 deps list contains a too wide range of acceptable MarkupSafe versions,
as a result MarkupSafe v2.1.0 contains changes that break Jinja2
See pallets/markupsafe#286
@MetRonnie
Copy link

MetRonnie commented Feb 18, 2022

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
Copy link

thetic commented Feb 18, 2022

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
Copy link
Member

davidism commented Feb 18, 2022

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
Copy link

thetic commented Feb 18, 2022

is this documented anywhere?

@pradyunsg
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants