Proposal: Remove Python & Go bindings to their own repositories

[Gadgetoid]

I don't believe having the Python & Go code here is a good idea, for many reasons but most prominent of all is that they add unnecessary burden to the maintainer, @jgarff, who must deal with PRs and issues against the language ports, in addition to the core C library.

It also sets a precedent that other language ports should be PR'd into this repository, rather than maintained by domain experts in their own repositories. This doesn't result in a very good separation of concerns. Although I appreciate it catches the edge-case where an issue with the core library might be reported against a specific port.

Do we really need to be funnelling fixes/issues for Python, Go, Mono - https://github.com/jgarff/rpi_ws281x/pull/58/files - and Rust - https://github.com/jgarff/rpi_ws281x/issues/265 - bindings for this library through one person?

I have the solution for Python- While it will almost certainly come across as self-serving to some, I propose that we instead focus on Pimoroni's hard fork of the Python bindings which currently lives here: https://github.com/pimoroni/rpi_ws281x-python

Why?

• It's part of my job to maintain these bindings, so I have a vested interest in keeping on top of PRs and issues
• These bindings are packaged and distributed via pypi, they're what you're installing if you type sudo pip install rpi_ws281x. There is no distribution for the Python code in this repository.
• Right now we have duplication of effort- eg: https://github.com/pimoroni/rpi_ws281x-python/pull/1 versus: https://github.com/jgarff/rpi_ws281x/pull/266
• I am still planning to distribute these bindings, and rpi_ws281x itself, as deb packages and submit them for inclusion in the Raspbian repository (I already do this for many Python libraries).

Right now this repository has multiple outstanding PRs and issues concerning the Python bindings: https://github.com/jgarff/rpi_ws281x/pull/258 https://github.com/jgarff/rpi_ws281x/pull/192 https://github.com/jgarff/rpi_ws281x/pull/163

https://github.com/jgarff/rpi_ws281x/issues/252 https://github.com/jgarff/rpi_ws281x/issues/247 https://github.com/jgarff/rpi_ws281x/issues/225

Frankly, this stuff is making this repository a confusing mess. So this is my impassioned petition to ask @jgarff to find a maintainer for the Go bindings in this library, and for us to work together to EOL the Go and Python bindings maintained here.

Feedback, particularly from the major contributors here is much appreciated;

• Golang - @cpheps @pietrodn @darinkes @supcik
• Mono - @zivillian
• Rust - @jmurph2015

And in general @penfold42 and @jgarff

[DanielSSilva]

Sound like a good name, and it follows the "convention" :)

[penfold42]

Done

[JMurph2015]

How are we doing on this effort? Was the plan to eventually migrate the core, or are we going to leave it here?

[Gadgetoid]

I've raised a PR to deprecate the go and python bindings in this repository in favour of the separately maintained ones- https://github.com/jgarff/rpi_ws281x/pull/317

As I note in my PR, it would probably be simpler just to delete them and leave a note in their respective READMEs directing users to the maintained ports.

Additionally @ladyada would like to regain control of the "neopixel" namespace for their own Pi/CircuitPython cross-compatibility project. I've removed "neopixel" from rpi-ws281x-python and shipped v4.0.0 to pypi, but the outdated bindings in this repository would also conflict with their package. Mothballing these old Python examples/bindings ASAP would probably save us some support issues with clashes in future since Adafruit are keen to forge ahead with a unified CircuitPython API that will include examples/tutorials covering the use of neopixels, but not with this library.

[Gadgetoid]

The Golang and Python bindings have been unceremoniously dropped in https://github.com/jgarff/rpi_ws281x/pull/479

I think that concludes this issue.