Closed dermotduffy closed 1 year ago
Many thanks for your suggestion. Since the motionEye HA addon is used quite much, and motionEye is about to release with Python 3 support (dropping Python 2 support) and quite a bunch of other changes, it definitely makes sense to stay in touch about possible API changes.
I also support integrating the motioneye-client
here. Without having a closer look yet, an interesting long-term project might be to have it used by motionEye itself for frontend>backend requests, to have a consistent library for 3rd party (and possibly own) alternative frontend/client/app/integration development. However, we definitely need more/more active developers here, for such to be done 😅.
@ccrisan @jmichault @zagrim @tunkio
What do you think (about moving the motioneye-client
into this organisation)?
Given the fact that there do exist external apps (clients) that use ME, it would sound reasonable to have the interface those apps are using closer to core ME development. Then again, those who don't want to use Python might have ended up writing their own already but offering at least one standard client interface implementation would IMO still make sense. The idea of having a sort of built-in API would of course be beautiful but as you said @MichaIng that would require "some" extra work :smile:
I do feel a bit bad commenting here knowing I probably won't be able to up my activity with this project any time soon :disappointed:
I do feel a bit bad commenting here knowing I probably won't be able to up my activity with this project any time soon 😞
No need to feel bad, none of us is currently investing much time. You did great contributions to this project. I'm happy for your opinion and reviews by times 🙂.
@MichaIng @zagrim Thanks for the feedback -- just following up on this again. If you'd like me to go ahead with this, and you have the permissions, if you create a new motioneye-client
(or equivalent) repo under this organization, and give me full privs on it, I'll move all the code over, archive the existing repo and continue my light maintenance in the new location. On the other hand, if you'd rather keep it separate, i.e. status quo, that's just fine too. Thanks!
I think best would be if you transferred the repo to the motioneye-project organisation. That way all existing links are automatically redirected, full commit history and all settings are preserved etc. So for users nothing changes, and even Home Assistant CI would just continue to work. But let me add you to the orga first.
@MichaIng That does sound like a better idea, but requires I have permission to create new repos in the organization:
From the docs: "To transfer a repository that you own to an organization, you must have permission to create a repository in the target organization" [ref].
A quick fix, and a minor leap of faith, might be to grant me that permission, I do the transfer, and you revoke that permission as I am extraordinarily unlikely to ever need that permission again -- but if you have a better idea ...
Just done.
Thanks @MichaIng . I've transferred the repo.
I made you admin of the repo and approved the PAT. Public repo creation for orga members is actually not a problematic permission. I'll leave it like that.
@MichaIng Your call, thank you -- verified initial access works.
The library test infrastructure currently uses codecov.io to maintain and report on coverage (enforced goal: 100%). It is complaining about access to the organization information -- I've taken the liberty of requested access so I can continue to report/track on code-coverage, but if you're not comfortable approving that for whatever reason I can remove codecov tracking.
Access granted. Would be great to move that to GitHub actions by times, to not grant 3rd parties access beyond what is public anyway, and have full control over the CI. But can be a larger task, I know, and adds an additional maintenance burden as well...
@MichaIng The CI uses Github actions anyway. Since the CI will always fail if coverage is not 100%
, really all codecov was doing was providing a dynamic badge. I've ripped it out. Go ahead and revoke that access -- on reflection it's not worth it for a silly dynamic badge.
Otherwise everything seems to be working now!
It might make sense for the package to have a secondary maintainer "just in case". No expectations that maintainer does anything unless I was to suddenly disappear (I'd rather not be a SPOF). If this sounds like a good idea, and if you have a pypi
username, happy to register you as that emergency backup maintainer.
Okay, indeed for the dynamic batch it's probably not worth it, especially if CI pipeline assures 100% anyway. I wonder if there is a way to achieve this with GitHub actions as well. What would work is to send a commit with the result to the repo itself. Or there is a smarter way 😄.
I think this bug is done: Thanks for your help @MichaIng !
If you're interested in having "emergency" write access to the package (since you already have access to the repo!), as per my suggestion at the bottom of this comment just let me know.
Thanks again for all the help.
Hello,
I am the author and maintainer of the async motioneye client -- a very simple library to allow you to query your motionEye instance. The most notable use of this library is from Home Assistant to query/control motionEye instances via this library (I am also the maintainer of the Home Assistant motionEye integration, which uses this library).
Any interest? I am happy to continue the (very low) effort in maintaining the library -- it just feels like having it under the
motioneye-project
might be a more suitable home if the main motionEye development team were open to it.Let me know!
Thanks, Dermot.