Too many RPI GPIO forks

[tomer-w]

Hey @thecode, @raboof, @gwhiteCL,

Sorry for contacting you here, I wanted to start a thread with all of you and this seemed like the right place as this is the original post HA fork of the RPI GPIO library. Hope this is fine with you.

We got to situation which there are too many forks of this is small integration and it is not helping the community.
@thecode fork is the oldest, has the most users, fully registered with HACS but does not have the Raspberry Pi 5 support and will become obsolete if not get back in shape.
@raboof seems to want to contribute RP5 support, for whatever reasons didn't get the support he needed to check it in, started a new fork with this important work but for whatever reasons decided to put his work on https://codeberg.org/ which makes it incompatible with HACS and will have low chance to become mainstream for users who needs this.
@gwhiteCL got it back to GitHub, added few features and tweaks over previous work but don't have full HACS integration and workflows like what we had in the original @thecode repo.
I wanted to contribute a feature and had to do it in two repos as I originally had RP4 and now I need to do it again as I moved to RPI5 and decide if I want it to work for me or get more exposure.
For the sake of the HA community, we should try to converge on a single GitHub based location for this work. It is too easy to fork but it doesn't serve us. think about HA itself if it had to fork every time someone had some idea for improvement.
I suggest integrating back the latest codebase based on @gwhiteCL work to @thecode repository. This will get the best visibility and the latest feature set. All three of you should become maintainers as you made a major contribution to this project. There are other options we can follow if needed. I'm sure that we can get to some agreement for the future of this important integration.

(Please forgive me if I got the history wrong, this is just me being bad GitHub historian and not trying to provide wrong / not complete information)

[raboof]

@raboof seems to want to contribute RP5 support

Actually my motivation was that I wanted support for systems that have more recent versions of libgpiod2 (and not necessarily the RPi-specific APIs). The RPi5 support was contributed by @aguedob

for whatever reasons decided to put his work on https://codeberg.org/ which makes it incompatible with HACS

I'm not sure I understand why HACS only works with GitHub and not with other forges, perhaps that's something to bring up on their side? I don't use HACS myself.

[tomer-w]

I'm not sure I understand why HACS only works with GitHub and not with other forges, perhaps that's something to bring up on their side? I don't use HACS myself.

I agree with you that this is a bit strange but I don't think this will be solved by us or in a short while so I think we should just accept the current reality that if we want to have meaningful integrations for HA it should be developed in GitHub.

[raboof]

OK. If you don't even tell them that'd be something that would be useful to you then you can be certain it will not be solved, though ;)

[tomer-w]

Agree, I'm not HACS nor https://codeberg.org/ expert. It seems you care about that, and you should try to understand if there are real limitations or not. In this thread I want to focus on the right way forward for our project and for now we should focus on one of the GitHub options: The @thecode repository, @gwhiteCL, or new one. As I said, I favor @thecode option as it has the most visibility (177 stars), but we can decide something different.

[tomer-w]

Adding @jdeneef. Sorry for missing you in my original investigation. I thought @gwhiteCL took the code directly from @raboof but I was missing that lot of the work was done by @jdeneef.
This is just making my point stronger that we have too many ports. I still think we should merge the latest work to this repo and make all the relevant contributors as maintainers and have a single place for the community to use.
Any thoughts about this? can I/someone merge all the code to here?

[jdeneef]

Thanx for adding me! I rewrote from scratch, copied mainly documentations for backwards compatibility with @thecode. Change from @gwhiteCL is merged some time ago.

[tomer-w]

Hey @jdeneef, happy to have you here.
Do you see any problem of merging it all back to @thecode repo assuming he will agree to share control over this repository with you?
@thecode, are you willing to give @jdeneef maintainer rights to this repository?

[thecode]

@thecode, are you willing to give @jdeneef maintainer rights to this repository?

I prefer it will start by making a PR with the changes when they are accepted I can add another maintainer(s).

[tomer-w]

Who will do the initial merge of all the code which developed outside of this repository is something @jdeneef can do or someone else (like me if needed). The question is whether after this is done, more people will be able to make progress as needed. I saw the original PR by @raboof was not handled in timely manner which started this fork shenanigans and I understand why it is better to have few people who can contribute to this to make it an active project.

[gwhiteCL]

Hi all, my only contribution was a small change in the documentation in @jdeneef's fork. I agree that one well maintained implementation would be great.

[tomer-w]

@thecode, i can start migrating the code from https://github.com/jdeneef/ha_gpiod but it will break the support for the legacy yaml. Are you ok with this? I think it is fine but I don't want to spend time on this if you think it is a problem.

[thecode]

@thecode, i can start migrating the code from https://github.com/jdeneef/ha_gpiod but it will break the support for the legacy yaml. Are you ok with this? I think it is fine but I don't want to spend time on this if you think it is a problem.

I think as part of the code migration we should also migrate YAML to config flow. We can't just break something for existing users. How would you feel if you press "update" in HACS and find out your sensors stopped working?

You can find in this PR an example how to support YAML and create an issue that ask to remove the YAML: #112

[tomer-w]

I meant only breaking the super old format:

# Basic configuration.yaml entry
switch:
  - platform: rpi_gpio
    ports:
      11: Fan Office
      12: Light Desk

This was already obsoleted probably few years back. I think that it is ok to break (which is quite common in HA) and keep the current format:

switch:
  - platform: rpi_gpio
    switches:
      - port: 11
        name: "Fan Office"
      - port: 12
        name: "Light Desk"

[thecode]

I meant only breaking the super old format:

This was already obsoleted probably few years back. I think that it is ok to break (which is quite common in HA) and keep the

Yes that is ok to remove the obsoleted YAML

[tomer-w]

Cool. I will try to create a PR for that. I will be glad to get ack from @jdeneef for this as well.

[jdeneef]

sry, not yet following what you are trying to do? I sort of was planning to add my setup to hacs sometime since the original is not working (at least on rpi) any longer, but feel free to find a better/alternative solution? I'm currently maintaining for my own purpose, but if anyone can use this code that's fine to me, that's and to get it into HACS is why it's on github. Not really working with github too much, any tips/ ideas welcome, I'm happy to share this code.

[tomer-w]

Just found another fork which was missed by my original research: https://github.com/jlinford/ha-gpio owned by @jlinford. Another attempt to fix the RP5 no support issue.

@jdeneef what i'm trying to do is to fix the original mess that HA made when they removed the GPIO integration from the official HC code base. Before this move there was a single integration which probably everyone used. Now after they did, it branched out to so many integrations which each has its own tweaks. I think for the sake of the community we should share all the improvements we made and not keep branching out and have so many flavors to choose from. If someone wants to make it better, they should try to send a PR to the common repository instead of forking further.

[jdeneef]

Great work. I would not know what it would mean on activities, so if you need something from me please share

fwiw rpi5 is not an issue, see jdeneef/ha_gpiod#1 (comment), was a different gpio path

[matwho]

Please let me know if I can help test anything - getting RPI GPIO working again in HACS is very important! Thanks for all your efforts on this everyone.

[tomer-w]

Hey @thecode , @jdeneef,

I just merged the cover fix which makes the gpiod-rpi5 branch working again. I think I will do a bit more testing this evening, but we are getting ready to merge to main. Any open concerns?

[thecode]

Hey @thecode , @jdeneef,

I just merged the cover fix which makes the gpiod-rpi5 branch working again. I think I will do a bit more testing this evening, but we are getting ready to merge to main. Any open concerns?

@tomer-w Please make sure any commits are made via pull requests and not directly merged. I am a collaborator on many repositories and changes are made via PRs after they are reviewed.

There are few things that needs to be fixed on your last PR but now they can't be reviewed.

Last please use https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github#squashing-your-merge-commits before merging.

[tomer-w]

You are right. I should use a PR for that. I dont use to work with people here on github. I can do git reset --hard and push to this branch so I can submit it again via PR. Let me know if this is what you want me to do.

[thecode]

Would be easier so when branch is ready we can merge it without review

[tomer-w]

Done: #297
It is a bit different than previous commit as I merged better to align with the coding standard here.
Also tested the change on my emulated cover and it is now working correctly.

[thecode]

I think we can merge it to main, for release we need the following steps:

1. Make a PR to merge from the branch to main, please give it a nice description that explain what we do here as this will be the major title on the release notes, some like: "Merge changes from @jdeneef fork to support new gpiod library and bring support for Raspberry PI 5."
2. Add yourself as code owner, please do it on a separate PR so it will be listed on the release notes. You can also add @jdeneef but I prefer make a separate PR himself so he is listed on the release notes. (title something like "Add @tomer-w as code owner"
3. Make a PR to bump version and create a release

   ha-rpi_gpio/custom_components/rpi_gpio/manifest.json

   Line 9 in 24f7d39

   "version": "2022.7.0"

4. I suggest we also bump the minimum HA minimum version

   ha-rpi_gpio/hacs.json

   Line 3 in 24f7d39

   "homeassistant": "2022.7.0"

   to something from this year, maybe 2024.9.0 so we don't have to deal with older releases.

Great work, thanks!

[thecode]

I am creating a release

[tomer-w]

Ack. Not making any more changes.

[tomer-w]

I think you should also delete the rpi5 branch now when it is merged.

[thecode]

You can freely create/delete/edit branches, just make sure to create PRs from branches to main so we can review them. Thanks!

[tomer-w]

Amazing!! All done. Now waiting to hear about the bugs :).
I want to thank @jdeneef for contributing his spinoff and @thecode for teaching me new things about how to work on HA integrations and GitHub in general.

@jdeneef, I really hope that all future work you will have in this area will be integrated into this repository.

I think we can now close this discussion.

[il77781]

Thanks to everyone involved!