Python installation results in split, arbitrary libraries

[reolinkcameraapi]

Python installation results in split, arbitrary libraries

[barretobrock]

Update: for more clarity on my suggestion, I've forked the repo and made the structural changes I suggested. NB! The README and other root-level files (e.g., Pipfile, test.py) have been either significantly modified or removed altogether. If the above assumptions I made were valid, I can put these changes in a separate pull request so that your project-level files remain unaltered.

[Benehiko]

HI @barretobrock thank you for using the library, really appreciate your input. I will look into refactoring the library as you have mentioned, but I will need to hold back on that for a bit since it will introduce some breaking changes if someone is using the library straight from GitHub. So I'll do this once I've sorted some other changes I want to make and then bump the version to v0.1.0.

[barretobrock]

Sounds good. Happy to help either way.

[Benehiko]

that would be great, I wanted to remove the openCV dependency before doing that, but it seems I can't find a proper RTSP client implementation in python3. So it's been taking longer than expected. I suppose, let's just do the refactor and then I'll get rid of the dependency at a later stage. I'm open for a PR if you're willing 👍

[barretobrock]

Yep, I can likely submit a PR this weekend.

Regarding RTSP clients, I have limited experience with them, but in the ~2 implementations I've seen the package provider will simply provide an easy way for the user to obtain the RTSP url or stream and then let the user make the decision about what client they want. Here's an example of that from Amcrest's package. I think if you decided to go this route, you could include in the examples a use case for using openCV without having to include it in the requirements. Anyway, just my 2 cents.

[Benehiko]

That would be great 👍

Yeah in the current release I updated it to only return the image stream (using cv2) with an example of how to view the stream using cv2 (here). So the plan is just to replace the cv2 dependency with a smaller alternative and keep the example as is - meaning the return data will be the same. I have found some RTSP clients that do return a raw stream, but it would need a bit of work for it to be considered stable enough to include in this library. I have done something similar in the Go library, but it actually had a proper library to work from.