opencv-python-headless wrong version

[Alek96]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

After installing opencv package, depended opencv-python-headless library was installed as well.
Which is correct, but the version of opencv-python-headless library should be 4.9.0.80, not 4.9.0.
As version 4.9.0 does not exist.
https://pypi.org/project/opencv-python-headless/#history

pip freeze | grep opencv-python-headless
> opencv-python-headless==4.9.0

Installed packages

# Name                    Version                   Build  Channel
opencv                    4.9.0           qt6_py310h681cb09_612    conda-forge

Environment info

conda version : 24.3.0
    conda-build version : not installed
         python version : 3.12.1.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=zen2
                          __conda=24.3.0=0
                          __glibc=2.35=0
                          __linux=6.5.0=0
                          __unix=0=0
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
               platform : linux-64
             user-agent : conda/24.3.0 requests/2.31.0 CPython/3.12.1 Linux/6.5.0-26-generic ubuntu/22.04.4 glibc/2.35 solver/libmamba conda-libmamba-solver/23.12.0 libmambapy/1.5.3
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

[hmaarrfk]

I guess we have been using major.minor.path and pypi has been using major.minor.path.release_increment and we simply don't use their release increment.

How did you come to "expect" the .80 version to be installed?

Did you pip freeze from a conda+pip environment then try to recreate with conda only?

Unfortunately that is expected to be quite buggy and not always compatible. I want to say "please just remove the .80" in your freeze results.

[hmaarrfk]

As an addendum, the main concern we are trying to avoid is users having opencv-headless in a requirement for a package from pip.

The "best practices" are:

1. Install whatever you can from conda-forge
2. Install what you need with pip.

Unfortunately, in such a case, opencv-headless will be installed from from pip to be installed over the version from conda-forge and may cause some incompatibility.

With our latest package, pip will think, no matter what version is installed, that both opencv-python and opencv-headless are installed. Always. This is a choice to avoid the conflict above.

[Alek96]

How did you come to "expect" the .80 version to be installed?

Did you pip freeze from a conda+pip environment then try to recreate with conda only?

I am using conda+poetry to create my working environment. Conda is used to install the most important packages (python, conda-lock, mamba, pip, poetry, pytorch, pytorch-cuda, opencv) and poetry is used to install the additional ones. Unfortunately, one of the packages managed by poetry (albumentations) is dependent on opencv, which causes poetry to try to uninstall library opencv-python-headless library in version 4.9.0 and install it in version 4.9.0.80.

[hmaarrfk]

If you are on Linux, all the packages you listed can be installed by conda forge.

I'm happy to give pointers but I need more information like a full log of all the transactions that conda pip and petty are doing and the conda info and conda list information requested in the original issue template.

Looking at the albumentions source nothing indicates that it is pinning to the .90 version to me.

[hmaarrfk]

You also have the default channels enabled.

Please consider disabling the default channels and only enabling the conda-forge channel. That is all we support.

[hmaarrfk]

Just an FYI: the fact that you have:

           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch

in your conda info scares me.

I'm happy to help troubleshoot this further, but when I run

$ pip list | grep opencv
opencv-python             4.9.0
opencv-python-headless    4.9.0

i get both opencv-python and opencv-python-headless installed which should in theory stop poetry from re-installing opencv-python-headless.

To further troubleshoot, I would need the full output of

conda list
conda info

as well as all the exact commands you use to create your environment starting with:

mamba create --name cv_test python conda-lock mamba pip poetry pytorch opencv

Truthfully, the fact that you listed pytorch-cuda seems to indicate that you are using the defaults + pytorch conda channels, which is not somehting that conda-forge (the community driven channel) supports.

If this is the case, your questions are best directed to Anaconda + Pytorch.

XREF:

• https://anaconda.org/pytorch/pytorch-cuda exists
• https://anaconda.org/conda-forge/pytorch-cuda does not

[traversaro]

How did you come to "expect" the .80 version to be installed?
Did you pip freeze from a conda+pip environment then try to recreate with conda only?

I am using conda+poetry to create my working environment. Conda is used to install the most important packages (python, conda-lock, mamba, pip, poetry, pytorch, pytorch-cuda, opencv) and poetry is used to install the additional ones. Unfortunately, one of the packages managed by poetry (albumentations) is dependent on opencv, which causes poetry to try to uninstall library opencv-python-headless library in version 4.9.0 and install it in version 4.9.0.80.

Do you have a way to reproduce this easily? I am encountering a similar problem, and I would like to understand how to properly deal with this.

[Alek96]

To fix this, I manually changed opencv-python and opencv-python-headless to version 4.9.0.80.
I renamed the package directory and changed the METADATA file information stored inside to match the correct version.
To find where the package was installed, type pip show opencv-python

[traversaro]

@Alek96 can you show us an example using poetry that is affected by this? I encountered something similar in huggingface/lerobot#145 and just using 4.9.0 instead of 4.9.0.80 as constraints seems to be working fine.

[Alek96]

Sure, this is my repository: https://github.com/Alek96/ultrasound_fetal_images
To install it and see the problem, please run make install.

I can create a sample project with fewer dependencies if you want.

[traversaro]

Thanks! Just to understand, can't you just fix the issue by changing the constraint in https://github.com/Alek96/ultrasound_fetal_images/blob/1be42b5a5f349c6926f910d3639714350de6ef9c/pyproject.toml#L25C1-L25C37 to be "^4.9.0 or similar?

I know that may sound "fix on your side a problem on the conda packaging side", but the situation with the opencv python package is a bit unusual. Basically the 4.9.0 portion of the version is the actual opencv version, while the .80 is not part of the opencv version, but it is assigned arbitrary by https://github.com/opencv/opencv-python/tags , and we have no way to know which tweak version (i.e. the .80 portion of the version number) will be used for a given opencv version.

Furthermore, the tweak portion of the version is used by opencv version to indicate if there was an updated version of the wheel (a bit like we have build numbers in conda), from https://pypi.org/project/opencv-python-headless/#history see for example 4.7.0.68 and 4.7.0.72 , where the same opencv version 4.7.0 is associated to two opencv-python versions, i.e. 4.7.0.68 and 4.7.0.72 . In that situation, which tweak version should we used?

[traversaro]

It is a bit unorthodox, but as I see this problem more and more (see also https://github.com/search?q=%224.10.0.84%22&type=code), I wonder if a possible solution (at least for inequality constraints) without any additional maintenance burden is just to declare opencv-python metadata installed by conda-forge as _._._.1000.

The only other alternative that I can think of is to design the CI to fail every time the version is raised (to avoid that new version are accidentally merge), and require a mantainer to manually change the _._._.x version every time a new opencv version is released, but that can only be done if one of the mantainers is on board on this.