Closed decathorpe closed 7 months ago
I think this might be fixed with #18 ?
I don't think so - maturin itself depends on pyproject-toml 0.8.1, pep440_rs 0.3.6, and pep508_rs 0.2.1: https://github.com/PyO3/maturin/blob/v1.4.0/Cargo.toml#L65-L76
Updating the pep508_rs dependency in pyproject-toml makes pyproject-toml compatible with the latest version of pep440_rs, but that doesn't help for any projects that depend on pyproject-toml ^0.8
and pep440_rs ^0.3
- there are types from pep440_rs that leak into the public API of pyproject-toml, for example:
pyproject_toml::Project.dependencies
pub field : Option<Vec<Requirement>>
withpep508_rs::Requirement.version_or_url
pub field: Option<VersionOrUrl>
withpep508_rs::VersionOrUrl::VersionSpecifier
variant: VersionSpecifiers
from pep440_rs
Which is why bumping the dependency on pep440_rs to a semver-incompatible version is in itself a semver-incompatible change in pyproject-toml (as it was in pep508_rs), even if it might not be obvious.
Side note: Bumping the dependency on pep508_rs from 0.2.1
to 0.3.0
in your linked PR would cause a similar problem, since types from pep508_rs also leak into the public API of this crate (see previous comment for an example).
I updated the Fedora Linux package for pyproject-toml to the latest version today, and our CI started complaining that maturin now fails to build:
It looks like types from pep440_rs are part of the public API of pyproject-toml, and it was updated from v0.3 to v0.4 between release v0.8.1 and v0.8.2. This is a breaking change (since pep440_rs is part of the public API of pyproject-toml), and should probably have been released as v0.9.0.