conda-forge / opencv-feedstock

A conda-smithy repository for opencv.
BSD 3-Clause "New" or "Revised" License
63 stars 59 forks source link

opencv-python-headless wrong version #408

Open Alek96 opened 5 months ago

Alek96 commented 5 months ago

Solution to issue cannot be found in 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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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:

traversaro commented 4 months ago

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 commented 3 months ago

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 commented 3 months ago

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

Alek96 commented 3 months ago

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 commented 3 months ago

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?