Open Interpause opened 3 months ago
related discussions:
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.)
Expected behaviour
Depending on opencv-python has always been an issue, depending on whether libraries used
opencv-python
,opencv-python-headless
,opencv-contrib-python
oropencv-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 insidesetup.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:opencv-meta
->opencv-python
opencv-meta[headless]
->opencv-python-headless
opencv-meta[contrib]
->opencv-contrib-python
opencv-meta[contrib,headless]
->opencv-contrib-python-headless
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
[x] This is not a generic OpenCV usage question (looking for help for coding, other usage questions, homework etc.)
[x] I have read the README of this repository and understand that this repository provides only an automated build toolchain for OpenCV Python packages (there is no actual OpenCV code here)
opencv-python