Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing Python 3.11 #278

Merged
merged 5 commits into from
Oct 12, 2023
Merged

Conversation

michaelcdevin
Copy link
Collaborator

Description

Python 3.11 has been out for almost a year and all of our dependencies now support it, so this changes our allowed Python versions. See #270.

Type of PR

  • Bug fix
  • New feature
  • Documentation
  • Other: Package management

Checklist for PR

@cmichelenstrofer
Copy link
Member

Other than making sure it is compatible, are there any new capabilities we would benefit from using? @michaelcdevin

@michaelcdevin
Copy link
Collaborator Author

I don't see any new capabilities with Python 3.11 that we could use. 3.11 seems largely focused on speeding up CPython, and so we should see those benefits anyway since WecOptTool is already written in a pretty Pythonic fashion.

Copy link
Collaborator

@ryancoe ryancoe left a comment

Choose a reason for hiding this comment

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

Good to merge after you decide how to address my comments

README.md Outdated
@@ -10,7 +10,7 @@ The Wave Energy Converter Design Optimization Toolbox (WecOptTool) allows users
Refer to [WecOptTool documentation](https://sandialabs.github.io/WecOptTool/) for more information, including project overview, tutorials, theory, and API documentation.

## Getting started
WecOptTool requires Python >= 3.8. Python 3.9 & 3.10 are supported.
WecOptTool requires Python >= 3.8. Python 3.9 through 3.11 are supported.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we may have had a conversation about this in the past where we decided we'd only support a finite number of Python versions (maybe 2) - should we change this to 3.10 & 3.11?

Copy link
Member

Choose a reason for hiding this comment

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

it was 3. But I am OK with reducing it to 2 to make the CI quicker. We are usually one version behind the latest Python anyways, so 2 should be far behind enough

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sounds good, I was wondering about how many versions we should support. 6c62be4 removes 3.9 as a supported version leaving only 3.10 and 3.11

@@ -19,7 +19,7 @@ jobs:
fail-fast: false
matrix:
os: ["ubuntu-latest", "macos-latest", "windows-latest"]
python-version: ["3.9", "3.10"] # CHANGE: Python version
python-version: ["3.9", "3.10", "3.11"] # CHANGE: Python version
Copy link
Collaborator

Choose a reason for hiding this comment

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

As with below, maybe reduce to just 3.10 and 3.11 - this will also help keep the CI run times from getting too much longer.

@michaelcdevin michaelcdevin merged commit ca587ad into sandialabs:main Oct 12, 2023
10 checks passed
@michaelcdevin michaelcdevin deleted the update_py_versions branch October 25, 2023 01:45
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