CDO

hi nils!

there are errors during the package update process that are non-reproducible on a local machine. Hence the delay

cheers
ralf

Hi Ralf,

I understand that there are errors during the packaging (https://code.mpimet.mpg.de/boards/2/topics/16287). Since it has been more than 6 months, it would be nice to point everyone to an alternative for the time being.
That is why suggested to do one of the following:
a) Mark the current Conda version as deprecated until updates resume.
b) Place notes at https://anaconda.org/conda-forge/cdo and the Anaconda wiki entry to use Spack as an alternative.

This way, everyone is aware of the problem and can use the newest version of CDO (with all the bug-fixes).

Cheers,

Nils

Hi there

I know this is not prioritary for CDO-developers - and I understand not all the release can reach conda-forge - but it would be great conda release if a new release can be provided in the near future.

We are really loving using CDO via conda since it simplifies a lot of deployment issues, we are still using 2.5.0 but it would be great to have 2.6.0.

Hi Paolo!

the plan is: release 2.6.1 will get a conda package (in about 2 weeks). the problem is with certain operators, which create wrong results when build as a conda package. Conda uses a target for compilation that provides maximum portability but lacks certain level of precision, which can be problematic for certain algorithms.

sry for the delay. I did not want to publish a conda package which potentially gives incorrect results - hence the delay

cheers
ralf

Thanks Ralf, the explanation makes a lot of sense, and I see your concerns.
I will be then waiting for the new release, fingers crossed it will work smoothly!

if you are in a pinch and need something locally, you can check the package manager spack. I keep the CDO package up-to-date. But it requires a different level of will to install things compared to a pre-build conda version. And you can hardly ship software environments as easy.

Thanks Ralf! Our problem is that we use CDO inside a pipeline of python tools (e.g. https://github.com/jhardenberg/smmregrid, https://github.com/DestinE-Climate-DT/AQUA) where we usa conda-forge for deployment of all binary dependencies. I could explore spack but as far as I know it has not the same grade of portability (actually I feel that pixi should be the way to go for the future). Having only major version on conda-forge is already good for us, CDO is very stable for our goals.

thx for the background

• what is pixi?
• do you always need the latest CDO version?

if you ship software environments I think you fix the packages version anyway to avoid possible conflict on the client side

The plan was and still to support conda-forge as a dedicated CDO binary for the future. Before the problems with the rbf-interpolation this was nobrainer for the linux platform.

Hi Ralf,

- Pixi is a recent package manager written in rust. https://pixi.prefix.dev/latest/ It seems like a notable update with respect to conda, but as far as I know it works on conda-forge. Some more info there: https://jacobtomlinson.dev/posts/2025/python-package-managers-uv-vs-pixi/

- No, there is no need to have the most updated one. We are happy with a stable version, but times to times we encounter issues and we are happy to keep pace to the more recent one.

That said, for us it was important to know that you are still supporting conda-forge, if only a fraction of the updates get there for us it is not a big deal as mentioned above.

Thanks for all your work!

thx for the links. I saw uv in othr pls workflows sometime ago, but did not dig into it.

IMO the logical next level is nix - but dont tell anyone. there is a higher nerd-lvl requirement to work with it in production. So I doubt it's a good solution for the user-community as a whole.

spack can great in the hand of admins and developers who are willing (or in need) to build software on the target system.

cheers!

cdo-2.6.1 has just made it to conda-forge.

Yes thanks, this is great!
I already tried :-) and might found a problem, not sure if it is expected or not https://code.mpimet.mpg.de/issues/12385

I think it is supposed to work just like in 2.6.0