New Major Versions Released! Flask 2.0, Werkzeug 2.0, Jinja 3.0, Click 8.0, ItsDangerous 2.0, and MarkupSafe 2.0

written by David Lord on 2021-05-11 in Releases

The Pallets team is pleased to announce that the next major versions for our six core projects have been released!

This represents two years of work by the Pallets team and community, there are a significant number of changes and exciting new features. Check out the logs for every project to see what's new. Flask depends on the five other libraries, be sure to read them all if you're upgrading Flask.

Installing and Upgrading

Install from PyPI with pip. For example, for Flask:

pip install -U Flask

The projects have all dropped support for Python 2 and 3.5, requiring Python 3.6 as the minimum supported version. We plan to follow CPython's supported versions as our supported versions.

Some less common parts of the projects, or parts that we've determined are better served by external implementations, have been deprecated. Previously deprecated code has also been removed. Testing tools such as pytest enable showing deprecation warnings automatically, and can turn them into errors so that you can see early what you may need to change in your project.

While we strive to avoid compatibility issues, there may turn out to be incompatibilities either directly or through other dependencies your project uses, such as Flask extensions. Over the next few weeks, the ecosystem around our projects will continue to update to improve compatibility as necessary. We encourage you to use tools such as pip-compile and Dependabot to pin and control upgrades to your dependencies to avoid unexpected changes.

Renaming the Default Branch

We are joining the PSF, CPython, and Django, among many other projects, in renaming the default branch of our repositories to "main". GitHub makes this transition easy, see their documentation about how it works for maintainers and users.

If you have a local copy of the repository you'll need to rename its branch to "main".

$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main
$ git remote set-head origin -a

If you were installing from a GitHub archive URL such as https://github.com/pallets/flask/archive/refs/heads/master.zip, you'll need to rename that link to use "main".

Release Highlights

These are a few of the great new features and changes to be aware of in the projects. Check out the linked changelogs for the full lists of changes.

  • All Projects
    • Support Python 3.6 and above only. Removing the compatibility code makes the code faster, as well as easier to maintain and contribute to.
    • Comprehensive type annotations have been added to the code. This makes type checking your own code more useful, and allows IDEs to provide better completion and help.
    • Use tools such as pre-commit, black, flake8, and pyupgrade to ensure the code and new PRs follow the same style consistently.
  • Flask 2.0
    • Support async views and other callbacks such as error handlers, defined with async def. Regular sync views continue to work unchanged. ASGI features such as web sockets are not supported. We will continue exploring how to add more support for async.
    • Blueprints can be nested under other blueprints, allowing a more layered approach to organizing the application.
    • Add route decorators for common HTTP API methods. For example, @app.post("/login") is a shortcut for @app.route("/login", methods=["POST"]).
    • Better CLI errors when an app could not be loaded. Running the development server shows errors immediately, they are only deferred on reloads.
    • A new Config.from_file function to load config from any file format.
    • The flask shell command enables tab completion like the regular python shell does.
    • When serving static files, browsers will cache based on content rather than a 12 hour timer. This means changes to static content such as CSS styles will be reflected immediately on reload without needing to clear the cache.
  • Werkzeug 2.0
    • Parsing multipart/form-data has been optimized and shows a 15x speedup, especially for large file uploads.
    • Locals use Python's ContextVar to allow working across async coroutines instead of only threads.
    • All request and response code has been merged into single classes instead of composing multiple mixin classes.
    • While this is not a public API yet, the Request and Response classes are becoming sans-io. This will allow us to better support sync and async use cases in the future.
    • The test client always returns a Response class that includes a reference to the original request, environ, and any redirects that were followed.
    • datetime objects returned by some headers and functions are timezone-aware.
    • URL routing understands ws:// and wss:// schemes and will route appropriately. While there is no direct support for websockets, this allows other projects to use Werkzeug's routing.
    • Move Flask's implementation of send_file and send_from_directory to Werkzeug.
    • The debugger no longer uses jQuery, which significantly reduces the size of the package.
    • The reloader is smarter about watching or ignoring directories.
    • The development server avoids showing 0.0.0.0 and warns about not running in production.
    • Colors are shown correctly in the server log on Windows.
  • Jinja 3.0
    • Async environments and rendering no longer requires patching. This feature will continue to be improved now that async is natively supported.
    • Blocks can be marked as required.
    • Variables set in blocks or loops can be accessed in context functions, as well as inner scoped blocks. Macros have access to the current template globals.
    • Filters and tests used within if blocks and ternary statements can be undefined at runtime. Tests have been added to check if a filter or test is available, to allow optionally using them.
    • I18N supports pgettext and npgettext.
    • NativeEnvironment supports enable_async mode.
  • Click 8.0
    • The shell tab completion system has been completely rewritten. It now allows every command, group, parameter, and type to provide custom completion, supports sending metadata such as the type to the shell for better native support, and provides a way to add support for new shells.
    • style supports 256 and RGB color codes supported by modern terminals, as well as the strikethrough, italic, and overline styles.
    • New class attributes make it easier to customize the core objects.
    • The context can manage resources that use context managers across commands. For example, this makes it easier to manage a database connection.
    • Options with multiple=True or nargs don't require setting a default, and properly validate the format of a default if it's given.
    • Options can be used as only a flag to use a default value, or prompt for a value only if the flag is given.
    • Prompts validate using the option's custom callback in addition to its type.
    • Help formatting and short help message generate has been improved.
    • Command line arguments on Windows support glob patterns like *.txt and ~/config.json, since the Windows terminal does not support this automatically.
    • Messages shown to users, such as validation and errors, are marked as I18N translatable with gettext.
  • ItsDangerous 2.0
    • Added support for key rotation by passing a list of valid keys instead of a single key.
    • datetime objects are timezone-aware.
  • MarkupSafe 2.0
    • Wheels are provided for 33 Python version / OS / architecture combinations, to make installing with speedups easy. Newly added are ManyLinux 2014 and OSX Universal 2 wheels.

Follow and Get Involved

Follow our blog RSS feed or our Twitter @PalletsTeam to get future updates. We also have an official Discord server https://discord.gg/pallets for chatting, asking questions, and contributing to the projects.

If you're interested in contributing, each project has a guide showing how to get started with a development environment and the tools we use. Check out the issue trackers for each project for what to work on. Use the Watch feature on GitHub see new issues, PRs, and the discussions we have around them.

The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.

Click here to donate. ❤

For Enterprise

The Pallets team and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.

Learn more.

Thank You!

We've made amazing progress, both by working through the backlog of issues and PRs, as well as growing the team and community. We have so many more exciting things in store. Look for more updates soon on community projects such as documentation translations and FlaskCon Online 2021! Thank you so much for using, supporting, and contributing to the Pallets projects!

New Flask, Jinja2, Click, Werkzeug, ItsDangerous, and MarkupSafe major release candidates

written by Philip Jones on 2021-04-29 in Releases

The Pallets team is pleased to announce that release candidates are now available for the next major version of each project.

Check out the changelogs for every project to see what's new:

Please help us prepare for the final release by testing the prerelease versions and reporting any issues you have. To upgrade to pre-releases with pip, use the --pre flag, e.g.:

pip install -U --pre Flask

These new major versions all drop support for Python 2 and 3.5, requiring Python 3.6 as the minimum supported version.

Release highlights

These are a few highlights, see the changelogs linked above for the full release details. More detailed posts about each project's highlights will be made with the final releases.

  • All projects (Jinja coming soon) now provide type hints.
  • Flask gains limited async/await support.
  • Flask supports nested blueprints.
  • Flask tells the browser to cache static files more intelligently, so changes to CSS or images show up immediately.
  • Flask introduces short form route decorators, such as @app.post() as a shortcut for @app.route(methods=["POST"]).
  • Click's shell completion system has been rewritten.
  • Click will now prompt for values where they are omitted.
  • Werkzeug now provides send_file and send_from_directory helpers.
  • Werkzeug's test client always returns a Response object.
  • Werkzeug's multipart parsing performance increases by a factor of 15.

Release date

The Pallets team is aiming to release on or before PyCon 2021, i.e. a target release date of the 11th of May 2021.

Click 7.1 Released

written by David Lord on 2020-03-09 in Releases

The Pallets team is pleased to release Click 7.1.

Read the full changelog to understand what may affect your code when upgrading.

  • Drop support for Python 3.4. This will be the last version to support Python 2.7 and 3.5.
  • Multiple fixes in low-level Windows compatibility code.
  • Colored output in Jupyter notebooks on Linux and Mac.
  • Updated Bash and ZSH tab completion support. Add support for Fish.
  • Better formatting when option help text contains newlines.

This also fixes a packaging issue from 7.0 where the project name in the package metadata was changed to "Click" with an upper case "C". This has been reverted, the name is now correctly reported in all lower case, "click".

Version 8.0 Coming Soon

As outlined in Ending Python 2 Support, 7.1.x will be the last version to support Python 2.7 and 3.5. The next version will be 8.0 and will support Python 3.6 and newer.

Install or Upgrade

Install from PyPI with pip:

pip install -U click

The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.

Click here to donate. ❤

Werkzeug 1.0.0 Released

written by David Lord on 2020-02-06 in Releases

The Pallets team is pleased to release Werkzeug 1.0. Werkzeug is the low-level WSGI and HTTP toolkit that powers Flask. It's been almost 13 years since the first commit, and this milestone for the project brings many fixes and changes. Read the full changelog to understand what may affect your code when upgrading.

  • Drop support for Python 3.4. This will be the last version to support Python 2.7 and 3.5.
  • Remove most top-level attributes provided by the werkzeug module in favor of direct imports. If you haven't already, use version 0.16 first to see deprecation warnings while upgrading.
  • Cookies support the samesite='None' option. Cookies are parsed as a MultiDict instead of overwriting repeated keys.
  • The development server supports 2-way TLS, making it easier to develop applications that inspect client certificates.
  • When building URLs with host matching, the current host is accounted for when deciding what rule to build.
  • When defining and matching URL rules, consecutive slashes are merged by default to match the behavior of common HTTP servers.
  • The Accept header preserves order for tags with equal quality and considers options on each value. The Accept-Language header can match the primary tag if the specific value is not present.
  • Added CORS header attributes to Request and Response.
  • A URL rule can be marked as a websocket, in which case it will only match for wss:// requests. This allows async web frameworks to use Werkzeug for routing.

Version 2.0 Coming Soon

As outlined in Ending Python 2 Support, 1.0.x will be the last version to support Python 2.7 and 3.5. The next version will be 2.0 and will support Python 3.6 and newer.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.

Click here to donate. ❤

For Enterprise

The Pallets team and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.

Learn more.

Jinja 2.11.0 Released

written by David Lord on 2020-01-27 in Releases

The Pallets team is pleased to release Jinja 2.11.0. Read the changelog for the full list of changes. Some of the bigger changes include:

  • Drop support for Python 2.6, 3.3, and 3.4. This will be the last version to support Python 2.7 and 3.5.
  • A new jinja2.ext.debug extension adds a {% debug %} tag to quickly dump the current template context.
  • A new ChainableUndefined type allows silently ignoring attribute access on undefined variables.
  • Loop context variables like loop.length and loop.nextitem work better in both sync and async environments.
  • Improved compile and runtime performance.

Version 3.0 Coming Soon

As outlined in Ending Python 2 Support, 2.11.x will be the last version to support Python 2.7 and 3.5. The next version will be 3.0 and will support Python 3.6 and newer.

The package name will remain "Jinja2" and imports will remain jinja2. "Jinja2 3.0" looks a little weird, but given the years of community momentum behind the name, we concluded it was less disruptive to keep it as-is.

Install or Upgrade

Install from PyPI with pip:

pip install -U Jinja2

The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.

Click here to donate. ❤

For Enterprise

The Pallets team and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.

Learn more.

Ending Python 2 Support

written by David Lord on 2019-12-17 in Meta

Upstream support for Python 2.7 is ending on January 1, 2020. Pallets is joining the community of open source projects ending support for Python 2 at that time. Our statement and support plan are based on PyTest's announcement.

We will be dropping support for Python 2.7 as well as Python 3.5 and below, as their support windows have ended or will end around the same time. Future releases of each Pallets project will only support Python versions still supported upstream, which can be found in the Python Developer's Guide.

The last version branch of each core project to support Python 2.7 and Python 3.5 are:

  • Flask 1.1.x
  • Werkzeug 1.0.x
  • Click 7.x
  • Jinja 2.11.x
  • ItsDangerous 1.1.x
  • MarkupSafe 1.1.x

Each project will receive a major version bump to indicate support for only 3.6+:

  • Flask 2.0
  • Werkzeug 2.0
  • Click 8.0
  • Jinja 3.0
  • ItsDangerous 2.0
  • MarkupSafe 2.0

Thanks to the python_requires package metadata, Python 2.7 and 3.5 users with a modern pip version will install the last supported version automatically even if later versions are available.

The team will no longer backport patches for unsupported versions, but the branches will continue to exist. The team will be happy to accept patches contributed by the community for any severe security and usability issues until mid-2020.

We made this decision based on multiple factors. Foremost is ease of community contribution and maintainer availability. As time goes on, fewer contributors have used or are familiar with the differences between Python 2 and 3. Contributors and maintainers must keep track of an ever growing list of obscure compatibility issues and workarounds, and cannot use many modern features.

Over the last two years, we've talked to many developers and teams at conferences and meetups and heard overwhelming support for the move to Python 3. This is backed up by data collected from our community in a survey we ran during January 2019, with 92% of respondents already using or actively upgrading to Python 3. The PSF developer survey and PyPI statistics report similar majorities and show adoption continuing to increase.

Thank you to everyone in the community for your support, and to everyone who has made this transition a reality. We look forward to continuing to develop the Pallets projects with you!

Werkzeug 0.16.0 Released

written by David Lord on 2019-09-19 in Releases

Werkzeug 0.16.0 has been released. The only change is that most of the top-level attributes in the werkzeug module are now deprecated, and will be removed in 1.0.0.

For example, instead of import werkzeug; werkzeug.url_quote, do from werkzeug.urls import url_quote. If you are using these imports in your project, a deprecation warning will show the correct import to use. werkzeug.exceptions and werkzeug.routing should also be imported instead of accessed, but for technical reasons can’t show a warning.

These imports were supported by patching the werkzeug module to support lazy imports, but the implementation added complexity, and there was no clear design reason why some things were available and some weren't. It also masked some circular dependency issues. IDEs like PyCharm didn't know those lazy imports existed and were already correctly using the full imports.

Werkzeug 0.15.5 Released

written by David Lord on 2019-07-17 in Releases , Security

Werkzeug 0.15.5 has been released, containing bug and security fixes. The changelog lists the changes in detail, which include:

  • SharedDataMiddleware safely handles drive names in paths on Windows.
  • The reloader no longer causes an Exec format error in many common situations.
  • The reloader works around an issue when using the pydev debugger.

Security fix for SharedDataMiddleware on Windows

Prior to 0.15.5, it was possible for a third party to potentially access arbitrary files when the application used SharedDataMiddleware on Windows. This issue was assigned CVE-2019-14322.

Due to the way Python's os.path.join() function works on Windows, a path segment with a drive name will change the drive of the final path. This was previously addressed in the safe_join() function in Werkzeug 0.12.2, but SharedDataMiddleware used a separate implementation and so was not secured by the previous fix.

SharedDataMiddlware now uses safe_join() when fetching requested files. Projects using SharedDataMiddleware on Windows should update as soon as possible to receive the fix.

Thank you to Emre Övünç and Olivier Dony for responsibly reporting the issue. If you think you have discovered a security issue in Werkzeug or another of the Pallets projects, please email [email protected] with details.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

Flask 1.1 Released

written by David Lord on 2019-07-04 in Releases

The Pallets team is pleased to release Flask 1.1. The latest version is 1.1.1. Version 1.0.4 was also released.

  • Drop support for Python 3.4.
  • Bump minimum Werkzeug version to 0.15.
  • The way error handlers for InternalServerError and 500 work has been made more consistent. See below for more information.
  • app.logger once again takes the same name as app.name, reverting 1.0.x's behavior of hard-coding "flask.app". See below for more information.
  • jsonify supports Python's dataclasses.
  • Returning a dict from a view function will produce a JSON response. This makes it even easier to get started building an API.
  • A clearer error message is shown when a view returns an unsupported type.
  • URL routing is performed after the request context is pushed. This allows custom URL converters to access current_app and request. This makes it possible to implement converters such as one that queries the database for a model based on the ID in the URL.
  • CLI commands can be registered with blueprints using the new bp.cli attribute. These will be available as nested commands, for example flask user create.

Read the changelog for the full list of changes. Be sure to check the notes for the 1.0.x versions as well.

Change to Error Handling

Prior to 1.0, unhandled errors caused a generic InternalServerError to be returned, but only the handler for 500 was looked up for that, and the original error was passed to it. 1.0 made 500 an alias for InternalServerError, but these inconsistencies caused confusion over what errors were passed to what handlers.

As of 1.1, an error handler registered for InternalServerError or 500 means the same thing in all cases. It will always be passed an instance of InternalServerError, even if it was caused by an unhandled error of another type. The original error is available as e.original_exception.

If your project uses a 500 error handler that expects any exception to be passed to it, it should use e.original_exception instead of e.

Change to Logging

In 1.0, Flask's logging setup was greatly simplified. Part of that was hard-coding the name "flask.app" for the logger. However, that made it less clear whether Flask or the app was doing the logging, and made it impossible to distinguish between multiple apps in logs.

As of 1.1, app.logger again takes the same name as app.name. Flask will warn you if it detects logging configuration for "flask" or "flask.app" so you can rename that configuration appropriately.

For example, if your project is named example.py and you initialize your Flask app as Flask(__name__), then the logger will be named "example".

Install or Upgrade

Install from PyPI with pip:

pip install -U Flask

Pallets now accepts donations through the PSF in order to support our efforts to maintain the projects and grow the community. We greatly appreciate any support you can provide. Click here to donate.

Werkzeug 0.15.3 Released

written by David Lord on 2019-05-14 in Releases , Security

Werkzeug 0.15.3 has been released, followed closely by 0.15.4. Both fix bugs and compatibility issues. The changelog lists the changes in detail, which include:

  • The debugger pin is unique per Docker container.
  • Fix issues with the arguments to the Unauthorized HTTP exception.
  • Fix ProfilerMiddleware filenames, and get LintMiddleware working on Python 3.
  • Bytes passed to URLs will be correctly decoded rather than having a b prefix.

Debugger Pin Security

A minor security issue was addressed in this release. The debugger generates a unique pin per host to prevent unauthorized code execution. However, in Docker this pin would be identical across all containers. This release ensures each container uses a unique pin.

Thank you to Nikita Tikhomirov for responsibly reporting the issue. If you think you have discovered a security issue in Werkzeug or another of the Pallets projects, please email [email protected] with details.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug