-
Notifications
You must be signed in to change notification settings - Fork 318
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
Remove Python 3.8 from CI (#824) #826
base: main
Are you sure you want to change the base?
Changes from 8 commits
45e1dcd
a359573
ea5cac4
1930dcb
f9661f7
1972aaa
3e305b3
d7ff260
02adf68
e26bf81
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
numpy>=1.20,<2.0 | ||
ipython<8.13;python_version<'3.9' | ||
ipython<8.13;python_version<'3.10' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this change due to bumping the version we use from 3.8 to 3.9 and we just did not have the constraint right before in that it really applied to more than just 3.8 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a constraint (limits) over what is installed when it's needed to be installed. So that basically says if ipython is installed it should be less than version < 8.13 but with the caveat that this only for when the python version its being installed into is less than that value. So before it would have installed some version of ipython < 8.13 when using 3.8 and was not constrained in other cases so it would have used whatever version it got resolved to, which is likely much newer. Now with bumping the Python version there it will be constraining it to < 8.13 in Python 3.9, which it was not before. But then I do not know which jobs exactly end up needing/using it - I imagine its for the notebook ones - which we would have run on 3.8 (and 3.12) before but not 3.9. You could try and see without that constraint. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, I'll try out the tests without |
||
nbconvert<7.14 # workaround https://github.com/jupyter/nbconvert/issues/2092 | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
deprecations: | ||
edoaltamura marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- | | ||
Removed support for using Qiskit Machine Learning with Python 3.8, reflecting | ||
the upcoming EOL of Python 3.8 in October 2024. |
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 was expecting changing python version here and in the "needs" jobs would run them with 3.9 directly, but they appear to pick up 3.8 instead. What would you suggest in this case?
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.
How the (Branch Protection) rules work is you select from the jobs that are run which are required - its configured. The config still has the old jobs, but since they are no longer run they show up as required but of course they will never pass since they are not run. What needs to happen is that the new jobs that we require to pass are selected/configured into the rule and the old ones removed. You can see on PRs that do not change the jobs that things are still correct since the jobs configured in the rules are the ones that are run. As this changes things we will need to update the rules. Its something we end up doing from time to time is jobs are changed, such as dropping a Python version or adding a new one. Changing the rules just needs to be coordinated with this PR being merged as the rules will affect other PRs from the moment its changed since the rule is for the branch the PR targets.
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 understand, thanks @woodsp-ibm. Let's merge #827 first and then un-require the old jobs. In which file would you suggest changing the job configs?