Rebuild for python311

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update python311.

Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/autotick-bot/actions/runs/3382538663, please use this URL for debugging.}

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[xylar]

@tomvothecoder, are we okay not supporting python 3.11 in cdtime? Will xcdat take over soon enough that we can stop maintaining this?

[tomvothecoder]

@xylar, based on the EOL dates for Pythons 3.9 (2025-10), and 3.10 (2026-10), there should be sufficient time for packages to move away from CDAT modules like cdtime to xarray/xcdat. We should be okay with not supporting 3.11.

I believe cdtime will be replaced by cftime (a dependency of xarray/xcdat).
Just an FYI for @chengzhuzhang and @lee1043 who work on e3sm_diags and pcmdi_metrics respectively.

[xylar]

@tomvothecoder, thanks!

based on the EOL dates for Pythons 3.9 (2025-10), and 3.10 (2026-10), there should be sufficient time for packages to move away from CDAT modules like cdtime to xarray/xcdat.

Hmm, I would probably want to move to python 3.11 for E3SM-Unified as soon as python 3.12 becomes available (just as I'm moving to 3.10 right now because 3.11 is avaliable). That would mean that I would need to drop cdtime (and all of CDAT) in about 1 year. Does that still seem feasiable?

[tomvothecoder]

Hmm, I would probably want to move to python 3.11 for E3SM-Unified as soon as python 3.12 becomes available (just as I'm moving to 3.10 right now because 3.11 is avaliable).

Your process makes sense to me.

That would mean that I would need to drop cdtime (and all of CDAT) in about 1 year. Does that still seem feasiable?

Below is a list of E3SM-unified packages that depend on CDAT modules (as far as I'm aware), their maintainer(s), and their status for porting over to xarray/xCDAT.

I think the maintainers need to scope the effort required for porting over to xarray/xCDAT. This will give us a clearer sense on whether 1 year is feasible for each package. I'll add this as an agenda item in an upcoming xCDAT meeting, then we'll get back to you.

In process of porting

• pcmdi_metrics (@lee1043)
• e3sm_to_cmip (@tomvothecoder)
  • Related issue: Refactor phalf.py and pfull.py to handlers.yaml E3SM-Project/e3sm_to_cmip#115 -- seems like fairly minimal work

Not started, scoping effort

• e3sm_diags (@chengzhuzhang, @tomvothecoder)
  • Related discussion: Explore replacement of CDAT modules with xarray/XCDAT E3SM-Project/e3sm_diags#607
  • From an initial judgement, I think refactoring e3sm_diags will require a substantial, dedicated effort. We're limited on FTEs working on e3sm_diags, so I'm not confident in a 1 year timeline.

Not started, need to scope effort

• zppy (@forsyth2)

[xylar]

@lee1043, @chengzhuzhang, @forsyth2 and @tomvothecoder, I guess this a bit of a warning then that we're going to be squeezed between cdtime and other CDAT libraries becoming non-functional with python 3.11 and other packages in the ecosystem probably wanting to adopt functionality from python 3.11 and newer. The move to python 3.11 is not the only problem (or even the first). There is also no support for new architectures like ARM and PPC so we're being left in the dust there, too. Soon enough, there may be incompatibilities with default libraries used by conda-forge as well. It's going to be increasingly hard to prop up the CDAT packages on conda-forge without any maintenance in the main repos.

[tomvothecoder]

@lee1043, @chengzhuzhang, @forsyth2 and @tomvothecoder, I guess this a bit of a warning then that we're going to be squeezed between cdtime and other CDAT libraries becoming non-functional with python 3.11 and other packages in the ecosystem probably wanting to adopt functionality from python 3.11 and newer. The move to python 3.11 is not the only problem (or even the first). There is also no support for new architectures like ARM and PPC so we're being left in the dust there, too. Soon enough, there may be incompatibilities with default libraries used by conda-forge as well. It's going to be increasingly hard to prop up the CDAT packages on conda-forge without any maintenance in the main repos.

I forgot to mention that complete CDAT support is dropping by the end of 2023, so all of these tools are forced to move over to xarray/xCDAT within a year anyways.

This just means the maintainers have prioritize this effort.

[chengzhuzhang]

Thanks for the discussion here and it is important to know about the timeline and potential consequence. Just to make sure that I understand, this python 3.11 compatible within one year requirement should only apply to packages that would participate in E3SM_U. Any stand-alone CDAT users should still be able to install and use with python version prior to 3.11, right?

Given the current progress in xcdat and the team's growing expertise in xarray, I'm fairly confident that given one year, the discussed packages should be able to transition using xarray/xcdat, unless this item is preceded by other priorities...

[xylar]

@chengzhuzhang, yes, exactly. Python 3.10 should be around until 2026 so it wouldn't be because of lack of python support that CDAT packages would become unusable. It would just be that at some point new versions with dependencies compatible with other conda-forge tools can't be built, so you can't use CDAT with other things.

[chengzhuzhang]

Thank you @xylar for helping me understand!

[lee1043]

Thank you @xylar and @tomvothecoder for the discussion. I second @chengzhuzhang on that the current progress would fit in the timeline of the python transition.

[forsyth2]

• zppy (@forsyth2)

E3SM-Project/zppy#346 to replace CDAT (E3SM-Project/zppy#80 for details regarding replacing cdscan specifically).