Support for Python 3.14

[Rogdham]

Summary

Currently, the requires-python classifier prevents installation of backports.zstd on Python 3.14.

I am creating this issue to share my thoughts and gather feedback on whether backports.zstd should be installable on Python 3.14. Below are the main arguments I have so far (I will keep this message updated). Feel free to chime in!

---

Incentive for standard library usage

The goal is to encourage use of the standard library.

If backports.zstd is allowed on Python 3.14, some users may install it unconditionally (as they would with zstandard, pyzstd, etc.).

The original purpose of backports.zstd was never to be just another library for zstd support, but to facilitate the transition to the standard library.

Lifetime of the backport

The library is scheduled for deprecation with the end of official support for Python 3.13 (October 2029).

Extending support to Python 3.14 and beyond is not the same maintenance commitment.

Does Python 3.14 always come with zstd support?

The zstd dependency is technically optional, and support depends on the availability of libzstd at both build and runtime.

However, in practice, zstd support appears to be consistently available:

• Windows: Supported in official installer.
• macOS: Supported in official installer.
• Linux: Most distributions include libzstd as a hard dependency for their package managers already. Moreover, libzstd is a dependency of their cpython 3.14 package. This has been confirmed for the following distributions already shipping CPython 3.14:
  • Debian unstable
  • Ubuntu 25.10
  • Fedora 42
  • openSUSE Tumbleweed
• Android and iOS: Support is expected to be available
• WASI/Emscripten: Probably not, but would they use the backport library anyways?

[emmatyping]

Windows

The official installer ships with zstd by default in the official installers, using libzstd from https://github.com/python/cpython-source-deps/tree/zstd.

macOS

The official installer includes libzstd. To confirm I opened the pkg file and looked at the Bom and it listed libzstd-1.5.7.dylib.

For Homebrew, I have left a comment on the 3.14 PR to ask they add zstd as a dependency for python@3.14.

Linux

Linux is always a bit of an anything can happen. Fortunately as you state, package managers for most Linux distributions already mean they ship libzstd by default. I also find that distro maintainers are pretty good at noticing new optional dependencies.

Android and iOS

These download and install libzstd as a dependency by default:

iOS: https://github.com/python/cpython/blob/85ec35d2ab8b764aefd6810efd59ff54c92554e9/Apple/__main__.py#L329

Android: https://github.com/python/cpython/blob/85ec35d2ab8b764aefd6810efd59ff54c92554e9/Android/android.py#L198

WASI/Emscripten

For these environments, it is often unlikely you will want to build with zstd for size purposes, plus you are already probably operating in an environment where zstd would be provided by the host (e.g. nodejs, web content compression in browsers).

BSDs

I don't see any ports in any BSD for 3.14, let alone 3.13, so it may take some time before these OSes get support.

---

Overall, all tiered environments should end up with zstd support other than wasi/emscripten, where they don't have things like xz anyway.

[emmatyping]

All the above being said, there is someone on an old RHEL trying to use 3.14 and being sad: python/cpython#139707

[qci-amos]

Can you at least have this be a NoOp for Python 3.14? An issue I'm having is that I use pip-compile to create a frozen set of python dependencies built on Python 3.11 that isn't working on Python 3.14 because my frozen set is missing the ; python_version<'3.14'

[Rogdham]

Freezing the dependencies for a version of Python and installing those on an other version of Python is indeed something I did not consider.

I am not 100% convinced that this is something that should be supported, but I see why people may assume it is, and why it is convenient.

---

What you ask for is to be able to install the library under 3.14, even if it raises an exception as soon as it is imported.

Technically, I think this means removing the <3.14 part of the requires-python instruction, and shipping wheels for 3.14 on PyPI.

The drawback is that consumers of library could just add backports.zstd in their dependencies without the ; python_version<'3.14' part, which means installing it for nothing if using 3.14+.

I will need to think more about this. If anyone else has any input, feel free to chime in!

[qci-amos]

According to ChatGPT, the solution already used by backports.zstd is correct and this is a problem that I need to deal with (i.e., solving for multi-python frozen sets or separated frozen sets for each python).

[Rogdham]

Alright in that case I am leaving it like it is! Feel free to write back if needed.