-
Notifications
You must be signed in to change notification settings - Fork 69
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
Drop support for Python 3.7 #355
Comments
Verde just dropped 3.6 for the upcoming 1.8 release. 3.7 works fine for us but maybe it's because of the way we started doing the CI tests. With fatiando/community#40 we can define the earliest supported version of dependencies and on CI I've been making it so we only test the end members. So Python 3.7 with the oldest versions of dependencies and Python 3.10 with the latest versions of dependencies. That avoids issues like this, where we could still support 3.7 while we support versions of xarray that had that support. That said, according to NEP29 we could have dropped 3.7 by now and support 3.8+ only. So it's up to you what you prefer to do here. But I would really recommend putting in the lower bounds of dependencies in Harmonica soon. I'll try to do that if I can find some time. |
For the record: the test failures were fixed in #356 so we are not having any problem with still supporting Python 3.6. And as discussed in the Fatiando Dev Call of 2022-10-26 we agreed that there's no specific reason to do this right now. I'm pushing this for |
@leouieda how do you go about determining the lower bounds for dependencies? Is it just trial and error with the GH Actions tests? Or is there some better, systematic method? |
@mdtanker We explain the dependency version support in the documentation pages of most (if not all) libraries. For example, in Harmonica: https://www.fatiando.org/harmonica/latest/compatibility.html#supported-dependency-versions Basically we try to follow NEP29, which is the Numpy policy for version support. Python has the PEP602 for their own release cycles. |
I guess I was asking more about how to determine which versions are compatible, not which versions should be supported (the 24month guideline). For example, Numpy < 1.20 doesn't work anymore with the Verde dev version due to the 'np.bool' deprecation. How would you figure out that it was specfically Numpy 1.20 which is the oldest compatible Numpy version? Would you just run a matrix of versions on the tests, and see that 1.19 fails but 1.20 passes? |
I see what you meant. And yes, most of the times we rely on tests passing or failing to determine if we have an incompatibility with a given version of our dependencies. Usually incompatibility issues appear with latest versions, when some feature gets deprecated or a breaking change happened upstream. To ensure that our libraries are still compatible with the older versions we just run a CI matrix branch with the oldest supported versions of the dependencies and don't incorporate any new code that would be incompatible with them. For the example you describe, looking at the deprecations in Numpy's changelog would be enough. But I suspect that Verde is still working with Numpy v1.19. At least the last test on the |
Xarray have dropped support for Python 3.7 and
we are now experiencing some test failures on Python 3.7 because of it (see https:/fatiando/harmonica/actions/runs/3323457986/jobs/5493825021). I think we should move on and drop support for Python 3.7 on Harmonica.@leouieda any thoughts? What's the status on Verde?
The text was updated successfully, but these errors were encountered: