opencv / opencv-python

Automated CI toolchain to produce precompiled opencv-python, opencv-python-headless, opencv-contrib-python and opencv-contrib-python-headless packages.
https://pypi.org/project/opencv-python/
MIT License
4.58k stars 859 forks source link

[Suggestion] Metapackage as solution to current issues with opencv as dependency #987

Open Interpause opened 6 months ago

Interpause commented 6 months ago

Expected behaviour

Depending on opencv-python has always been an issue, depending on whether libraries used opencv-python, opencv-python-headless, opencv-contrib-python or opencv-contrib-python-headless. I do know that opencv isn't designed as a plugin system, which is why it had to be done that way. But as a result, usually special workarounds like detecting inside setup.py what version of opencv-python is installed, or needing the user to manually uninstall then reinstall the version of opencv they want, is needed. This makes dependency management when depending on opencv complicated.

My suggestion is what if there could be an opencv-meta package instead, where which version is pulled in depends on extra flags. The mapping could be like:

This can be on top of the existing four packages to avoid breaking existing libraries. Given sufficient adoption of depending on opencv-meta rather than the different versions of opencv, it should hopefully resolve the dependency issues one day.

That said, I might not be thinking deep enough and there is still something seriously wrong about the above approach.

Issue submission checklist
geroldmeisinger commented 6 months ago

related discussions:

MatthijsBurgh commented 4 months ago

This would be really helpful. As when using Python package managers, i.e. Poetry, the package manager will resolve the correct versions of all dependencies recursively. So therefore when my package has a dependency on i.e. the headless opencv, but I want the normal version, as I want to visualize stuff. I get both. So I have to manually fix the situation by removing and installing packages.

While when this was done with extras instead of different packages, it would just resolve the different opencv dependencies to one package with the required extras, so no conflicts.

I think this is only be possible as the base version would be headless and Gui is an extra. As a library would want to use the headless version. But then the application, which is depending on that library, would want to use the Gui. Which would require the headless extra to not be added. Which is still causing conflicts.

(Preferably the opencv-python package is adapted to this new way of distributing instead of creating a new metapackage.)