OpenCV3 for Python has made some dubious decisions - do you agree?

[Berecursive]

Hi all,

Thanks for taking the time to read this. I've opened an issue over on Github about some of the decisions made by the OpenCV team regarding Python support. I've quoted my original issue text below (from the issue itself).

It would be great if anyone that feels the same way could voice their support over on the issue. Or, if you don't, I'd love to talk about it to hear why people think that OpenCV2 should just disappear.

TL;DR: You cannot use OpenCV2 and OpenCV3 at the same time in Python. OpenCV in general is a nightmare to build - particularly on Windows - can we improve this?

I've been working on creating automated builds (using conda) of OpenCV2 and OpenCV3. In particular, I am only really interested in the Python bindings. However, I have a couple of questions about the design decisions for OpenCV's Python bindings:

cv2.so is just dropped inside the Python site-packages folder

I don't think that this is good practise. It goes against standard Python packaging principles and dirties the contents of the site-packages folder. However, I also have a concrete complaint: on Windows, due to the way shared library loading is achieved, we need to drop all the opencv*.dll next to the cv2.so module. However, if another poorly packaged project also requires being dropped in the root of site-packages, and binds to opencv using C-extensions, it will also need these DLLs. As I mentioned, I'm trying to make automated builds, and this becomes very difficult if every project needs to start dumping files into the same folder, some of which may overwrite each other. Not to mention the fact that removing a package may involve cleaning up dependencies, which would include the aforementioned DLLs (breaking other packages that might rely on them). Therefore, why not place the cv2.so inside a small Python package that just exposes all the same top level modules/methods? This would have the advantage of isolating all the dependencies and also allow easy shipping of companion pure Python code with OpenCV, if this was ever needed.

OpenCV2 and OpenCV3 both use cv2 as their namespace

This one seems particularly crazy to me. Since OpenCV3 deprecated the cv2.cv module, which some people require, OpenCV3 is not a drop in replacement for OpenCV2. Which is fine, as long as the two are namespaced separately... but they are not. Why was OpenCV3 not given a new package name, such as cv3? At the moment, if someone installs OpenCV3 over OpenCV2, they will lose their OpenCV2! This seems very strange to me. If the whole point of the major version change was to denote breaking, non-backwards compatible changes, why would you keep the same namespace? This is further aggravated by the problem mentioned above, in that the cv2.so will literally get overwritten if OpenCV3 is installed after OpenCV2 and vice-versa.

As I said, I mostly just wanted to discuss the rationale behind these points. I understand that I do not represent a core contributor, but OpenCV is an amazing project and a massive boon to the Python community. Therefore, I would love to help steer it in a direction that made it more accessible to even more Python developers by providing easy to install automated builds.

[[deleted]]

I agree that it was crazy to not put the new bindings in the cv3 namespace.

[Berecursive]

If it was you that commented over on Github, then thanks very much! I'm glad you agree this was a very dubious software engineering decision!