Latest Results
Add TOML 1.1 -> 1.0 backward compatibility for `pyproject.toml`
[TOML 1.1](https://github.com/toml-lang/toml/releases/tag/1.1.0) introduces support for new syntax that older tools with TOML 1.0 don't understand.
Usually, the user is either in control of which tools need to read the TOML files or the TOML gets converted before publishing (`pyproject.toml` -> `METADATA` for wheels). The specific case where this doesn't work is when a user builds the source distribution of the package with a tool that only support TOML 1.0. Build tools need to parse `pyproject.toml` in source distributions to extract the `[build-system]` table, and if any other part of the file contains TOML 1.1 syntax, they fail to build. This generally doesn't trigger backtracking, so the user is left if a failure when any (transitive) dependency in their dependency tree has started using a single instance of TOML 1.1. Most package managers, including pip, are implemented in Python and use stdlib's tomllib, which only support TOML 1.0 up to including Python 3.14.
To work around this, we do a best-effort rewrite of `pyproject.toml` to TOML 1.0 during source distribution builds.
This approach is inspired by Cargo, which is successfully rewriting published `Cargo.toml`s for many versions. While the `toml` crate doesn't guarantee this downgrade is always done (https://github.com/toml-rs/toml/issues/1088), this crate is also used by Cargo, and this best effort rewrite is sufficient currently. Similarly following Cargo, we also add a `pyproject.toml.orig` to the source distribution.
https://discuss.python.org/t/adopting-toml-1-1/105624 went nowhere, but a best-in-class tool should do this transformation, so we're adding it.konsti/toml-backwards-compatibility Add TOML 1.1 -> 1.0 backward compatibility for `pyproject.toml`
[TOML 1.1](https://github.com/toml-lang/toml/releases/tag/1.1.0) introduces support for new syntax that older tools with TOML 1.0 don't understand.
Usually, the user is either in control of which tools need to read the TOML files or the TOML gets converted before publishing (`pyproject.toml` -> `METADATA` for wheels). The specific case where this doesn't work is when a user builds the source distribution of the package with a tool that only support TOML 1.0. Build tools need to parse `pyproject.toml` in source distributions to extract the `[build-system]` table, and if any other part of the file contains TOML 1.1 syntax, they fail to build. This generally doesn't trigger backtracking, so the user is left if a failure when any (transitive) dependency in their dependency tree has started using a single instance of TOML 1.1. Most package managers, including pip, are implemented in Python and use stdlib's tomllib, which only support TOML 1.0 up to including Python 3.14.
To work around this, we do a best-effort rewrite of `pyproject.toml` to TOML 1.0 during source distribution builds.
This approach is inspired by Cargo, which is successfully rewriting published `Cargo.toml`s for many versions. While the `toml` crate doesn't guarantee this downgrade is always done (https://github.com/toml-rs/toml/issues/1088), this crate is also used by Cargo, and this best effort rewrite is sufficient currently. Similarly following Cargo, we also add a `pyproject.toml.orig` to the source distribution.
https://discuss.python.org/t/adopting-toml-1-1/105624 went nowhere, but a best-in-class tool should do this transformation, so we're adding it.konsti/toml-backwards-compatibility Latest Branches
0%
xingzihai:fix/issue-18510-interpreter-cache-pollution -1%
ai-man-codes:feat/uv-publish-hashing 0%
konsti/toml-backwards-compatibility © 2026 CodSpeed Technology