Skip to content

Support Python 3.10 and 3.11 for Cookiecutter and Plone compatibility#645

Merged
audreyfeldroy merged 1 commit intomainfrom
support-python-310
Mar 8, 2026
Merged

Support Python 3.10 and 3.11 for Cookiecutter and Plone compatibility#645
audreyfeldroy merged 1 commit intomainfrom
support-python-310

Conversation

@audreyfeldroy
Copy link
Copy Markdown
Collaborator

@audreyfeldroy audreyfeldroy commented Mar 8, 2026

With this PR, BinaryOrNot installs on Python 3.10+ instead of 3.12+. All 213 tests pass on 3.10 through 3.14.

Honestly it hurts my heart quite a bit to lower the range. I was excited to use modern Python features like in #644, and to bump Cookiecutter itself to 3.12+. Supporting legacy Pythons is not something I enjoy or have free time for in my current situation, but I guess I'll do it for now 😿

I am doing this because @wesleybl raised this and because I like cookieplone. It gives me a lot of inspiration for the scaffolding tools I've been planning to build for https://github.com/feldroy/air. I'll merge this for now, then let's figure out a better solution somehow. Cookieplone folks, which specific users of yours are on 3.10 and 3.11? I'd like to really understand their use case for old Pythons.

BinaryOrNot installs on Python 3.10+ instead of 3.12+. The code uses
no 3.12-specific features, so lowering the floor is safe. All 213 tests
pass on 3.10 through 3.14.

Cookiecutter requires Python >= 3.10, and Plone's scaffolding tool
(cookieplone) depends on Cookiecutter. With requires-python >= 3.12,
pip refused to install binaryornot on 3.10/3.11, breaking the entire
chain. Thanks to @wesleybl for raising this via #634.
@audreyfeldroy audreyfeldroy marked this pull request as ready for review March 8, 2026 14:10
@audreyfeldroy audreyfeldroy merged commit 084e9d7 into main Mar 8, 2026
23 checks passed
@audreyfeldroy audreyfeldroy deleted the support-python-310 branch March 8, 2026 14:49
@wesleybl
Copy link
Copy Markdown

wesleybl commented Mar 9, 2026

@audreyfeldroy I mentioned more because Cookiecutter still supports Python 3.10. But if the idea behind Cookiecutter is to remove support, then that's fine. Cookieplone would have to follow the versions supported by Cookiecutter anyway.

My company still uses an OS that has Python 3.10 as standard. This isn't a justification, but it helps when packages support this version.

@davisagli @ericof FYI

@davisagli
Copy link
Copy Markdown

@audreyfeldroy We typically recommend running Cookieplone with uvx cookieplone which (unless pinned) uses the latest version of Python that uv knows about (currently 3.14 I think). So this sounds more like a requirement of @wesleybl's runtime environment than a requirement of Cookieplone.

We haven't dropped support for Python 3.10 yet in Cookieplone mainly because the stable version of Plone (6.1) still supports it. Plone itself tries to support a Python version until security support for it is dropped by the Python team (Oct 2026 for Python 3.10).

Anyway, I don't think you should let this keep you from moving forward with dropping support for Python 3.10 if that's what you want to do. We can pin cookieplone to older versions and we have test matrices covering them. It would help a bit if you:

  • increment the major version of the package when you drop support for an old Python
  • make sure cookiecutter does not require the new version of binaryornot unless it also drops support for Python 3.10 and increments its major version

/cc @ericof in case you have a different opinion from me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants