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

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:

• 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

• This is not a generic OpenCV usage question (looking for help for coding, other usage questions, homework etc.)
• 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)
• The issue is related to the build scripts in this repository, to the pre-built binaries or is a feature request (such as "please enable this additional dependency")
• I'm using the latest version of opencv-python

Start with the repository's build scripts and the metadata for the four existing OpenCV Python packages. Compare how dependency variants and extras could be represented, then review the issue discussion for constraints or objections. Done would require a maintainer-approved approach for introducing the proposed metapackage without breaking existing packages.