CDO

Hi Sylvaine!

There is a naming collision I might have to explain:

1. in the mamba/conda context there is a package called 'cdo' which contains the binary. Hence the python bindings packages must have a different name: 'python-cdo'
2. on the other hand you can install the python bindings using pip. In this context there is now packages for the binary. So here I chose the package name 'cdo' for the python bindings.

In fact I started it all with pip and joined the conda-forge maintainers for their package later. It might boil down to how you resolve the dependencies in poetry. Do you have your own registry? Do you relay on ether pip or conda. or both maybe?

best
ralf

Dear Ralf,

thank you for the prompt and clear answer! That explains indeed ;).
I guess my setup was also a bit convoluted and this now all comes clear:

1. Until recently, I was always using mamba/conda for handling my virtualenvs and most of the pkg installations therein, except in rare cases where I had to use pip, inside the conda-created virtual env. For packaging my python tools, I was mostly using the setuptools, with basically doing a manual config (and therefore I was using pip to install my own pkgs).
2. Now I'm experimenting poetry (I'm very new to it), but, for now, only in the context of packaging my own python codes, for easily creating the boilerplate config and handling my package dependencies. I am, a priori, not specifically interested in the virtual env functionality of poetry.

In playing around with that yesterday (with trying to package a small python code using the cdo python bindings), I was therefore inside a mamba-created virtual env. Trying to register the cdo dependency with poetry, I was convinced that the package python-cdo had to be declared. And there came the trouble. Understanding that cdo is a full pip pkg, ie containing the python bindings is the key. I guess I was almost getting there, trying to leave aside the python-cdo pkg and only have the cdo pkg installed, to check whether the python bindings wouldn't be already there, but given that my cdo pkg was installed with mamba and not with pip, I indeed was caught into this nasty name conflict.

Epilog: Now, uninstalling the conda-forge cdo pkg, and declaring cdo as the sole dep in the poetry framework, all works like a charm! Yeah

Answering your question about how are dependencies managed by poetry: by default, poetry relies on pypi, but it seems to have the ability to handle other (private) repositories as well (https://python-poetry.org/docs/repositories/). I guess this might therefore be possibly tweaked into relaying on conda-forge... (making things even more complicated ;D)

Thx for the explanation, Sylvaine!

Please note, that no matter what way you choose to install the python bindings, they need a working CDO binary somewhere in the environment. So if you drop conda/conda-forge you might end up without a working python package simply because you lost the CDO binary. If you stick to conda/mamba you will get both from the same source (conda-forge).

Currently I see no reason to worry about differences in the release-cycles of the pip-packages 'cdo' and conda package 'python-cdo' since conda-forge automatically builds a new version in case pip has one.

Or in other words: How do you declare the need for the CDO binary in your poetry?

Or in other words: How do you declare the need for the CDO binary in your poetry?

Humm... not so clear yet, but I guess there's a general solution of the whole problem here

--> I'll play a bit with that to see how functionl that is.

...and, to be complete in this thread so that it may be useful for later people: this stackoverflow thread is also interesting regarding the topic of poetry + conda