-
Notifications
You must be signed in to change notification settings - Fork 279
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
TST: how to drop CPython 3.8 ? #4302
Comments
I'm ramping up my allocation on yt. I'll try to give |
While dropping 3.8 is still not a high priority, it is slowly becoming more and more of a special case within the code base and the ecosystem (most of our most crucial dependencies have already dropped it). @Xarthisius may I ask what's your vision on this problem at the moment ? Is there anything you would like a hand with ? |
My vision is:
I coincidentally tested that recently during debugging one of the PRs. I'm testing it right now on Jenkins. |
and with some success, if I read correctly ! |
So with this done, I guess there are no technical blockers left so I will ask what other think about dropping 3.8 now (or soon) on the mailing list. |
I am not proposing to drop support for CPython 3.8 now. I just want to point out why this will be difficult because it'll need to happen eventually, and the sooner we prepare for it, the easier it'll be.
Timeline: when can we expect to drop it ?
To ensure the total number of versions we support at any given time stays bounded, and as long as new versions of CPython keep dropping yearly, we need to drop 1 version per year to keep up.
Following this motivation, the drop typically happens around the same time of year that a new version is released (see #2917 and #4101 for history), so the typical expectation would be that we do this around October 2023.
Were we to closely follow NEP 29 (which so far we have not, so it shouldn't be expected from us), it could be done as soon as April 2023.
Problem
CPython 3.8 is our oldest supported version at the moment, and is currently used for testing on Jenkins. This means we need to upgrade the Python runtime on CI before we are allowed to bump
requires-python
inpyproject.toml
. I expect this may be difficult and/or time consuming because all our answer-tests and image tests that rely on actual simulation data are run there, and many (not sure exactly which) of them usepickle
for reference storage. Now, Python objects saved to disk withpickle
are not guaranteed to be interoperable with different versions of thepython
runtime, so it is possible that some references cannot be salvaged and must be regenerated from scratch (then validated manually ?).To make things worse, the most we can upgrade these jobs is to Python 3.9, because newer versions (3.10+) are just not compatible with the test framework used for these tests (
nose
).It follows that dropping 3.9 (around October 2024 ?) will not be possible without leaving some of our test suite behind unless we can finish the migration to pytest before then, but that's an other story (sort of).
So I'd like to open the discussion as soon as possible, mostly with @Xarthisius who's still in the delicate position of being our only Jenkins maintainer, and @matthewturk, who's most aware of the issues we're having with transition to pytest.
I think (maybe naively ?) that we can afford doing only minimal manual validation for answers on Python 3.9 (the code base has been extensively tested on Python 3.9 for years now), which would make the process easier.
The better solution of course would be to push for the migration to
pytest
but that seems like an unreasonable amount of work for this timeline, given the history of this project.Thoughts ?
The text was updated successfully, but these errors were encountered: