-
Notifications
You must be signed in to change notification settings - Fork 476
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
Upgrade infrastructure to pixi/uv/ruff, bump minimum python version to 3.11 Develop #2132
Conversation
The main reason behind this change is to be able to define HAS_* as constants for typing purposes.
|
||
jobs: | ||
lint: | ||
runs-on: ubuntu-latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be a good idea to use os
in the matrix so that we define everything in one job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, but My I will use this commit to migrate as is, and then use future commits to do this.
- test-py310 | ||
- test-py311 | ||
- test-py312 | ||
- test-py313 | ||
numpy: [null, "numpy>=1.23,<2.0.0", "numpy>=2.0.0rc1"] | ||
uncertainties: [null, "uncertainties==3.1.6", "uncertainties>=3.1.6,<4.0.0"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dunno if its still relevant to test multiple versions of uncertainties
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure. My suggestion is that we use this commit to migrate as is, and the use future commits to do this.
|
||
|
||
# TODO: remove this warning after v0.10 | ||
class BehaviorChangeWarning(UserWarning): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is dead code I think we can safely remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so too. The same hapens with certain imports in compat (Self, Never, etc) but I would rather keep it as is until downstream libraries are aware. Again my suggestion is that we use this commit to migrate as is
CodSpeed Performance ReportMerging #2132 will not alter performanceComparing Summary
Benchmarks breakdown
|
.github/workflows/ci.yml
Outdated
matrix: | ||
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"] | ||
environment: | ||
- test-py39 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've removed support for 3.9 and 3.10 in pyproject.toml.
Maybe keep 3.10 for now according to https://numpy.org/neps/nep-0029-deprecation_policy.html
We can still support it until April 04 2025.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saw that you're using 3.11 only features though. Well I'mnot against of moving forward. Only thing might be some downstream that still support 3.10 like Metpy and others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new Pint version will be released on > April 05, I am not sure if we should. Maybe we can list what would be the burden of keeping Python 3.10
We could remove requirements.txt to since all is handled by pyproject.toml + PEP621 no ? |
pre-commit run --all-files
with no errors