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

Allowing recent version(s) of poetry-core #14931

Closed
icp1994 opened this issue Jan 28, 2023 · 1 comment
Closed

Allowing recent version(s) of poetry-core #14931

icp1994 opened this issue Jan 28, 2023 · 1 comment
Labels
A-Packaging Our Debian packages, docker images; or issues relevant to downstream packagers T-Other Questions, user support, anything else.

Comments

@icp1994
Copy link
Contributor

icp1994 commented Jan 28, 2023

Hi, due to multiple previous issues with updating poetry-core for synapse it has been upper bounded to v1.3.1 for some time now. To quote the relevant bit from the last discussion:

Discussed among the team. We'll constrain to <= 1.3.1 and will raise that upper bound to 1.3.2/1.4.0/another version if a) someone wants to use that version, and b) we can check that it's safe.

Will the team consider allowing (i.e., to check whether it's safe) poetry-core v1.5.0 for synapse v1.77? Or maybe a tracking issue for checking compatibility of latest stable release of poetry-core before a synapse release.

@DMRobertson
Copy link
Contributor

For cross-referencing, the quoted comment is #14085 (comment), though there was some discussion in #14079.

Will the team consider allowing (i.e., to check whether it's safe) poetry-core v1.5.0 for synapse v1.77?

We'd likely accept a PR which does this. I'm not sure what version of poetry-core you have in mind, but I couldn't see any obviously scary changes in the 1.4.0 and 1.5.0 releases.

AFAICS it should be sufficient to change

requires = ["poetry-core>=1.0.0,<=1.3.2", "setuptools_rust>=1.3,<=1.5.2"]
to include a new upper bound. The tricky bit will be testing that it works fine. Most of our CI uses poetry install (with a pinned version of poetry), which I think uses its own pinned version of poetry-core; I don't think CI would test what we want it to. (I think the cibuildwheel jobs will check that the wheel is installable under the latest allowed poetry-core, but it won't run any of the test suites afterwards.)

The best way to sanity-check that there aren't any surprise issues at runtime is probably to

  • bump the upper bound
  • pip install /path/to/checkout in a virtualenv
  • run the unit tests. I think python -m twisted.trial tests from within the virtualenv should do it?

@squahtx squahtx added A-Packaging Our Debian packages, docker images; or issues relevant to downstream packagers T-Other Questions, user support, anything else. labels Jan 30, 2023
@squahtx squahtx closed this as completed Jan 30, 2023
@icp1994 icp1994 mentioned this issue Jan 31, 2023
4 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Packaging Our Debian packages, docker images; or issues relevant to downstream packagers T-Other Questions, user support, anything else.
Projects
None yet
Development

No branches or pull requests

3 participants