Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

pyproject.toml: Respect semantic versioning for requires #15727

Closed
wants to merge 1 commit into from
Closed

pyproject.toml: Respect semantic versioning for requires #15727

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/15727.misc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Allow building with poetry-core<1.7 and setuptools_rust<1.7 instead of <=1.6.0
2 changes: 1 addition & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -369,7 +369,7 @@ furo = ">=2022.12.7,<2024.0.0"
# system changes.
# We are happy to raise these upper bounds upon request,
# provided we check that it's safe to do so (i.e. that CI passes).
requires = ["poetry-core>=1.1.0,<=1.6.0", "setuptools_rust>=1.3,<=1.6.0"]
requires = ["poetry-core>=1.1.0,<1.7", "setuptools_rust>=1.3,<1.7"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pedantic I know, but semantic versioning would be <2 for both, since the minor releases are supposedly only meant to add backwards-compatible features.

The problem is that we've been burned by this (minor releases with breaking changes) in the past.

I think I'm with @DMRobertson here in that I'd rather keep these bounds defensive.
If we don't and the build system maintainers make a breaking release, this breaks the ability to easily install old PyPI packages or even old dependency-locked packages of Synapse from the git repository (because the build system is itself not locked, except by these bounds here).

I understand the pain this causes for packagers and sorry for that, but there isn't really a perfect choice here. (We're very happy for packagers to patch/sed the bounds up to fit your packaging situation in exchange, as well as to bump up the limits when released packages emerge that we can test in CI.)

build-backend = "poetry.core.masonry.api"


Expand Down