Unfortunately xGCM doesn’t really have any active maintainers right now. We had been hoping that somebody who uses it regularly would be interested in stepping up to help maintain it, but that hasn’t happened. @christopher.wolfe it would be great if you (or anyone else) were interested in that.
There doesn’t seem to be much activity on the GitHub repo
To give more detailed context: xGCM (like xhistogram and xrft) was originally created by @rabernat , then developed primarily by @jbusecke and myself whilst we were part of Ryan’s oceanography research group at Columbia. There were a number of other contributors, but the only other person with write access is apparently @dcherian. At the time all of us worked in oceanography research, but now none of us do, and none of us have extra time to help maintain xGCM anymore (because we’re too busy either running companies or maintaining several other open source packages).
Does anyone know what the current status of xGCM is?
It is stable in the sense that it is usable, and for handling staggered grids it has a fairly solid and complete feature set. However, the scope of the package is potentially much larger, and there is unbounded amount of extra features that could be added, for example to deal with different grid topologies and numerical methods, some of which we started work on.
Has xGCM been superseded by some other tool that I should be using?
I’m not aware of anything in python, but the Julia community might have some equivalent by now.
swimming in depreciation warnings
My main contribution to xGCM was to quietly refactor almost the entire internals in the name of performance at scale with dask (see this SciPy talk). I consider that project a success in that it helped push the boundaries of geospatial workloads at scale with dask ((1), (2)), but the refactor also allowed us to start a big deprecation cycle that we never got around to finishing. This is likely the source of many of the deprecation warnings you are seeing. (Others are probably due to more minor changes to xarray’s API that happened in the last 3 years.)
is it worth going through and fixing up the depreciated code?
xGCM did have a significant number of users, and should still be fairly stable, as the main dependency is xarray, which is very stable. But there is technical debt to pay down by finishing this deprecation cycle. If the package is useful to you then this shouldn’t be too difficult to do, but it would require taking ownership. I would love to see that happen, and I am more than happy to spend a few hours talking you through the current code and what would need to be done, but I’m not going to submit any more pull requests myself to the package (and I imagine @rabernat @jbusecke and @dcherian feel similarly).
EDIT: If no-one steps up we could take the step of explicitly archiving the package, to avoid any confusion or false promises of maintenance. I would really rather not have to do that though.