Replies: 4 comments
-
I think coordination between xESMF and ESMPy is highly desirable. I believe we're in the process of phasing out 3.8 and it would be great to sync with you guys. @huard @aulemahal can we have a call early next year with @billsacks ? |
Beta Was this translation helpful? Give feedback.
-
Great! Also, FYI, I just made some fixes for ESMPy that are needed in some situations with python 3.12+ (with many thanks to @xylar for one of the fixes and general guidance). These will be available starting in the upcoming ESMF 8.8 release. |
Beta Was this translation helpful? Give feedback.
-
Hi! Yes we could have a call in january. In my opinion, xESMF could be closer to SPEC0 as it is a package of that "world" (pangeo / xarray / etc). I think we didn't drop python 3.8 simply because nothing was broken. |
Beta Was this translation helpful? Give feedback.
-
Thank you @aulemahal and @raphaeldussin . A call in January sounds great, so whenever you get a chance you can let me know some times that work well for you. |
Beta Was this translation helpful? Give feedback.
-
I help maintain ESMPy. I am making some changes to be more deliberate about what versions of python and numpy we support, both with updates to our pyproject.toml and through including more versions in our nightly testing. (This discussion thread gives context.)
Since xESMF is a very important user of ESMPy, I'd like to coordinate our version support with what xESMF supports. I see that you currently list support for python >= 3.8 and numpy >= 1.16. For now - for our upcoming ESMF 8.8 release - I have added ESMPy testing with versions as far back as python 3.8 and numpy 1.19, which is the earliest available version on conda, and I will list those as our minimum supported versions.
Moving forward, though, I would like to at least drop python 3.8 support, since it is end-of-life, and ideally come up with a version support policy that we can stick with over time. For example, I see that https://scientific-python.org/specs/spec-0000/ recommends supporting python versions for 3 years after their initial release and supporting core package dependencies for 2 years after their initial release. That feels a little too aggressive for ESMPy, given our support for operational centers and others who can be slow to upgrade their systems, but I'm thinking that perhaps something like 5 years of support for python versions (which is the typical support time frame for a given python version) and 3 years for NumPy might be reasonable.
Would it be reasonable for xESMF to adopt a support policy like this? If so, can we coordinate ESMPy and xESMF's support policies?
Beta Was this translation helpful? Give feedback.
All reactions