Skip to content

Set default python version 3.9 and fix strenum problem#135

Open
jacomago wants to merge 12 commits intomasterfrom
set-default-python-version-lower
Open

Set default python version 3.9 and fix strenum problem#135
jacomago wants to merge 12 commits intomasterfrom
set-default-python-version-lower

Conversation

@jacomago
Copy link
Contributor

@jacomago jacomago commented Feb 6, 2026

No description provided.

@jacomago jacomago self-assigned this Feb 6, 2026
@jacomago jacomago marked this pull request as ready for review February 6, 2026 14:20
@jacomago
Copy link
Contributor Author

jacomago commented Feb 6, 2026

I tried to get this check in the pre-commit, but adding all ruff lints wasn't enough, I had to add type checking... Which made the PR huge. So I'll stick with just this change for now.

@jacomago jacomago force-pushed the set-default-python-version-lower branch from 7dd8ea3 to e3862b6 Compare February 11, 2026 09:54
Copy link
Contributor

@tynanford tynanford left a comment

Choose a reason for hiding this comment

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

It's too bad the 1.8 release already included the update that was >= 3.11 but oh well. Let's make a new release after this PR is merged

Also can you update the README with the new minimum python version?

version="1.5"
readme = "README.md"
requires-python = ">=3.6"
classifiers = [
Copy link
Contributor

Choose a reason for hiding this comment

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

remove 3.6. - 3.8

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you not need 3.6 anymore? I'm happy to remove.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I read "default" in the PR description as planning to get rid of 3.6-3.8

It's up to the community what to do. I think there's value in making life easiest on the people using/deploying software in these open source projects. So it is good to keep support for older versions when it's not too much hassle and I would say keep 3.6. But I am fine moving to 3.9 too (RHEL 9 default) if no one else wants 3.6 support.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm wary of going beyond the python supported versions https://devguide.python.org/versions/. 3.9 is already end of life. Wouldn't be surprised if that starts breaking the ci soon.

Copy link
Contributor

Choose a reason for hiding this comment

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

Eh, I think the hassle is worth it to help the lab setups where there might just be one person trying to maintain all this EPICS software. But just my opinion

Copy link

@ralphlange ralphlange Feb 13, 2026

Choose a reason for hiding this comment

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

+1
At ITER - at 1 million records with less than 10 of ~160 plant systems delivered - we are struggling to migrate everything to RHEL 8 (that uses Python 3.6 as standard).

Copy link
Contributor

Choose a reason for hiding this comment

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

Side-point, but you might want to have a look at conda(/mamba, etc.) @ralphlange

Re py3.6, I am a bit torn: there may be sites that are limited to it, but EOL'd more than 4 years ago, and is becoming increasingly costly to maintain support for; that is at least what we have seen for the projects where we have tried to do so.

Copy link

@ralphlange ralphlange Feb 16, 2026

Choose a reason for hiding this comment

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

I know there are better solutions - it's simply not my decision to make.
Almost all ITER plant systems are in-kind contributions, and many take 5-10 years between prototyping and delivery. Which means we're getting deliveries based on versions/technologies of 5-10 years ago.

If supporting old versions is getting costly, drop it. We'll find ways.
Please don't drop it just because it's old.

Copy link
Contributor

Choose a reason for hiding this comment

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

We discussed it today and said that we either will build (but not test) from 3.6 or else maybe set up a dedicated (limited support) release branch for 3.6.

@jacomago jacomago force-pushed the set-default-python-version-lower branch from e3862b6 to 2f39dc5 Compare February 13, 2026 07:23
@jacomago jacomago force-pushed the set-default-python-version-lower branch from dfbfa02 to 3f12593 Compare February 13, 2026 13:13
jacomago and others added 2 commits February 16, 2026 16:06
Co-authored-by: anderslindho <44849690+anderslindho@users.noreply.github.com>
@jacomago jacomago force-pushed the set-default-python-version-lower branch from 3f12593 to 7368eb7 Compare February 16, 2026 15:06
@sonarqubecloud
Copy link

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.

5 participants