Drop support for Python 3.9
mfisher87 opened this issue · 9 comments
We are now in Q4 of 2024, and per SPEC0, it's time to drop support for Python 3.10. We still support 3.9, so perhaps we should drop 3.9 in our next release, and 3.10 in the following one.
This sounds scary, albeit is a best practice... empirically I think most of the Python code out there in tutorials still uses 3.9 I'd say let's hear the community on this one before dropping it.
This sounds scary, albeit is a best practice
Not just a best practice, but a policy we committed to! https://earthaccess.readthedocs.io/en/latest/user_guide/backwards-compatibility/#our-python-and-dependency-support-policy #471
I'd say let's hear the community on this one before dropping it.
What would this process look like? I'm really wary about having a community veto on following through with our policy. I'd rather have the process look like the community designs the policy, we follow it, and if it doesn't work, the community changes the policy. If we do have a community veto process, it should be tightly defined and time bounded.
Python 3.9 is at the very end of its life cycle, only receiving security fixes (and not bug fixes) until it's EOL in Oct. 2025. The scientific Python ecosystem, as described in SPEC0, started dropping support for Python 3.9 in Oct. 2023, and Numpy dropped support for it in its April 2024 release. Even Google CoLab, which is notoriously behind on updates, is currently running Python 3.10.12.
So yeah, I don't see any reason to keep 3.9 going forward -- if users are using 3.9 they can continue to use earthaccess v0.11.0 or lower.
For Python 3.10, I don't see a need to rush, but we could drop support in our next release. SPEC0 doesn't say you have to drop it immediately; it just communicates that users shouldn't expect support beyond those dates, so usually packages drop support 1-3 releases later. Since Google Colab is still 3.10, I guess keeping it makes sense, but once Google Colab updates, I don't see a reason to keep it at all since the are almost always the last to update.
I take the Google CoLab comment as the ultimate "what people are using" test. What about down the road we create one of those mini compatibility matrix just for the Python versions in the docs?
I take the Google CoLab comment as the ultimate "what people are using" test
🤔 it'd be nice to have a better understanding of what people are using earthaccess for and where.
I know we have a bunch of users using CoLab, and I'm pointing to it mostly because it's an environment users can't control well, so they are stuck with the provided Python version, and CoLab incredibly slow at updating. Other similar places are either better at staying up to date, or users can select the Python version they want.
The comment was not sarcastic haha I think CoLab is at the tail of adoption and hence a good measure on what is supported.
🤔 it'd be nice to have a better understanding of what people are using earthaccess for and where.
Speaking of something related, we used to have "used by" and now we don't, I think it's tied to having a dummy setup.py file, we can take a look at the current projects https://github.com/nsidc/earthaccess/network/dependents that depend on earthaccess.
We're drifting afeild here, but I'm not sure why we don't have the "used by"; it's still parsing our dependencies out of the pyproject.toml and recognizing we're in the pip ecosystem:
But this setting doesn't show up in our repository settings (for me at least):
https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository#changing-the-used-by-package
I agree with dropping support for 3.9 and that we should wait on dropping support for 3.10, even though SPEC0 recommends dropping it this quarter. Dropping 3.10 feels a bit aggressive. (Hard to believe 3.10 was released 3 years ago already.)