motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
3.85k stars 647 forks source link

Any interest in moving motioneye-client under this github project? #2682

Closed dermotduffy closed 1 year ago

dermotduffy commented 1 year ago

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.

MichaIng commented 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)?

zagrim commented 1 year ago

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:

MichaIng commented 1 year ago

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 🙂.

dermotduffy commented 1 year ago

@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!

MichaIng commented 1 year ago

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.

dermotduffy commented 1 year ago

@MichaIng That does sound like a better idea, but requires I have permission to create new repos in the organization:

Screen Shot 2023-01-28 at 11 36 05 AM

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 ...

MichaIng commented 1 year ago

Just done.

dermotduffy commented 1 year ago

Thanks @MichaIng . I've transferred the repo.

MichaIng commented 1 year ago

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.

dermotduffy commented 1 year ago

@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.

codecov

MichaIng commented 1 year ago

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...

dermotduffy commented 1 year ago

@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.

MichaIng commented 1 year ago

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 😄.

dermotduffy commented 1 year ago

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.